* [Wish List Requests 558 and 559] Civil Partnership

For Wish List Requests that have either (a) been progressed to the Wish List; or (b) been classified as duplicates, or as redundant because the requirement is already satisfied within FH and/or plugins; or (c) closed because it wasn't possible to arrive at a clear specification of the request within 15 months of it being raised.
avatar
jmy46
Newbie
Posts: 3
Joined: 07 Sep 2015 15:35
Family Historian: V6

[Wish List Requests 558 and 559] Civil Partnership

Post by jmy46 »

Please could we have an addition to the 'Marriage Status' drop down list?

I note that FH is happy with same sex marriages but I see no way of indicating a Civil Partnership.
User avatar
Jane
Site Admin
Posts: 8508
Joined: 01 Nov 2002 15:00
Family Historian: V7
Location: Somerset, England
Contact:

Re: Civil Partnership

Post by Jane »

There are a couple of options, either use the standard marriage fact and over-ride the sentence, or create a custom fact for Civil Partnership which ever you prefer.
Jane
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

Yes, the Family Status is not customisable, and is aimed more at Narrative Report wording.

As Jane says, either use the standard Marriage Event and customise the Sentence Template (see how_to:narrative_report_fact_sentence_templates|> Narrative Report Fact Sentence Templates) or create a custom Event called Civil Partnership in much the same way as the Extended Set offers the custom Family Separation Event (see glossary:work_with_fact_sets|> Work with Fact Sets/Fact Types).

If using the standard Marriage Event then either customise the specific fact Sentence Template just for the Civil Partnership couples, or customise the default fact Sentence Template conditional on same sex partners.
i.e. If both Principals are same Sex, then Civil Partnership wording, else standard Marriage wording.
e.g. {individual} {=TextIf(%CUR_PRIN.SEX% = %CUR_PRIN2.SEX%, "entered a Civil Partnership with","married")} {spouse/her/him} {date} {place} {their ages}.

So FH can indicate Civil Partnerships a number of ways and this posting can be moved to the General Usage Forum. This is the standard solution for any situation not covered by the standard facts.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
Jane
Site Admin
Posts: 8508
Joined: 01 Nov 2002 15:00
Family Historian: V7
Location: Somerset, England
Contact:

Re: Civil Partnership

Post by Jane »

Just to add a wrinkle to Mikes clever template, since same sex couples since 2013 can now have a Civil Marriage rather than a Civil Partnership.
Jane
My Family History : My Photography "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad."
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

Agreed, and for same sex couples in non-UK countries, Civil Partnership may also not be the correct ceremony.
Nevertheless, there are enough FH solutions I think.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
johnmorrisoniom
Megastar
Posts: 901
Joined: 18 Dec 2008 07:40
Family Historian: V7
Location: Isle of Man

Re: Civil Partnership

Post by johnmorrisoniom »

And in the Isle of Man Non same sex couples can have a civil partnership (Since 2016)
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

Having mulled this over for a while, it has a number of significant considerations.

It is not clear whether the Civil Marriage/Partnership events are still recorded in the UK GRO Marriage Index or in a separate UK GRO Civil Partnership Index that identifies the associated Certificate. Does anyone know?

Nevertheless, many users have techniques indicating areas of outstanding research using Queries, Diagram Box Conditions, Records Window Columns, etc. Those will typically use Expressions involving Marriage Events and their Source Citations. So using the standard Marriage Event for Civil Marriage/Partnership events avoids updating those Expressions to cater for custom Civil Marriage/Partnership events.

Also Plugins such as Lookup Missing BMD Records only check standard Marriage Events and would not know anything about custom events, so would give false indications for Civil Marriage/Partnership couples using custom events.

So there may be benefits in using a customisable standard Marriage Event that caters for Civil Marriage/Partnership events.
As an academic exercise, if nothing else, here is a solution that uses a field in the Marriage Event to customise the Sentence.
That field could be the Fact Cause, a labelled Fact Note, or the Family Custom Id.
It would hold the name of the ceremony such as Civil Partnership or Civil Marriage or whatever.
The Expressions shown below would replace the word married in the default Sentence Template as discussed earlier.
  • Fact Cause
    {=CombineText( "entered a ", %FACT.CAUS%, " with", "married" )}
  • Labelled Fact Note where the label is Status: but it could be anything such as Ceremony:
    {=CombineText( "entered a ", GetLabelledText( %FACT.NOTE2%, "Status: " ), " with", "married" )}
  • Family Custom Id
    {=CombineText( "entered a ", Field( GetRecord(%FACT%), 'FAM.REFN' ), " with", "married" )}
In each case it either uses the ceremony text from the field or defaults to the word married.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Civil Partnership

Post by ColeValleyGirl »

Occam's razor says updating the Marriage Event to have Civil Partnership as a status option is the right way to go as a solution, so I really think this ought to be a wish list request even though interim solutions are also possible.

My own interim solution is to use the standard event for Civil Partnerships with a status of <default> and add a note to the marriage the clarifies the situation with the specific words Civil Partnership. When we get an addition to the drop-down list of statuses, I'll be able to find the affected records with a simple search and update the status. My personal preference is to mess about with sentence templates as little as possible -- I don't use narrative reports at all, so any changes I do make can be very simple.
User avatar
mjashby
Megastar
Posts: 719
Joined: 23 Oct 2004 10:45
Family Historian: V7
Location: Yorkshire

Re: Civil Partnership

Post by mjashby »

For background information on Certificates see: https://www.gov.uk/marriages-civil-part ... ceremonies
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

@Helen, I agree that using the standard Marriage Event is the best option, in the same way as using the Census Event for the UK 1939 Register is the best option, and for the time being adjust the Sentence Templates if required for Narrative Reports.

However, I have some reservations about using Status to qualify the Marriage Event.
1) It is an FH custom extension Gedcom field (_STAT) that does not usually export to other products.
2) It is primarily used to define non-Marriage status, rather than qualify an existing Marriage Event.

My preference is to use the standard Cause (CAUS) field to identify what Ceremony caused the Marriage, with adjustment to the default Sentence Template as my earlier suggestion, and which needs no Wish List request to implement now.
That Cause field can even be customised into the Individual/Family Property Box alongside Status.
(However, this reveals a bug in FH when adding a Shared Details item to Individual Property Box it mutates into a Spouse Details item that inhibits editing of FAM data refs, but only if the % are retained around data refs.)

@Mervyn, thank you for the link, but that does not answer my question about the GRO Index entries.
My main concern is where the Lookup Missing BMD Records Plugin needs to search online for such civil ceremonies, but I suspect Ancestry & FMP will just add them to their usual Marriage collections.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
brianlummis
Superstar
Posts: 256
Joined: 18 Dec 2014 11:06
Family Historian: V7
Location: Suffolk, England
Contact:

Re: Civil Partnership

Post by brianlummis »

It is not clear whether the Civil Marriage/Partnership events are still recorded in the UK GRO Marriage Index or in a separate UK GRO Civil Partnership Index that identifies the associated Certificate. Does anyone know?
My main concern is where the Lookup Missing BMD Records Plugin needs to search online for such civil ceremonies, but I suspect Ancestry & FMP will just add them to their usual Marriage collections.
Mike, I wouldn't worry too much about the Plugin at the moment, as the first Civil Partnerships did not take place until December 2005 and the Marriage indexes at Ancestry & Find My Past only go up to 2005 so the numbers will be very small. :)

Brian
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Civil Partnership

Post by ColeValleyGirl »

I have some reservations about using Status to qualify the Marriage Event.
Why? It's already in place and already used in a way that doesn't export to other products; adding another value for the (legal) status of the relationship doesn't change that (plus FH already supports same-sex marriages which don't always export either). In fact, FH have already in effect repurposed the Marriage Event as a 'created family unit' event, qualified by a field that indicates the legal status of the union.

I do think that Divorced shouldn't be there as a status for the 'marriage'-- if a couple divorced, there's a differently (one hopes) dated fact for that, but that's a separate issue, and those of us who prefer two events are catered for already.
My preference is to use the standard Cause (CAUS) field to identify what Ceremony caused the Marriage,
The use you're suggesting for CAUS is a bodge -- ask me what the cause of a marriage is and I'd say Love/Money/Pregnancy/Immigration/insert your own reason here. CAUS is what leads to the event, not how it is enacted. And I'm always wary of using standard fields for non-standard purposes.

Anyway, how far would you take it -- differentiate between Marriage by Licence and Marriage by Banns? between a Jewish cermony and a Catholic one? Notes seems a much better way of handling the variations within a single legal status.

And finally :lol: I look forward to the day when FH handles the relationships of my group of polyamorist friends...
User avatar
LornaCraig
Megastar
Posts: 3190
Joined: 11 Jan 2005 17:36
Family Historian: V7
Location: Oxfordshire, UK

Re: Civil Partnership

Post by LornaCraig »

I do think that Divorced shouldn't be there as a status for the 'marriage'-- if a couple divorced, there's a differently (one hopes) dated fact for that, but that's a separate issue, and those of us who prefer two events are catered for already.
This was touched on in the topic Annulled Marriages (14770). FH uses the status values, including divorced, to affect the marriage link in diagrams, as set in Diagram > Options > Lines > Marriage Status Line Options.
Lorna
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

FH have already in effect repurposed the Marriage Event as a 'created family unit' event, qualified by a field that indicates the legal status of the union.
Helen, I do not understand what you mean here. Are you saying the Status field indicates the legal status of the union. If so, then that is nothing to do with the Marriage Event but is a qualifier on the Family record that is the 'created family unit'. In fact if a Marriage Event exists then in Narrative Reports the Status is ignored. Only when there is no Marriage Event does the Status of Unmarried Couple or Never Married affect the Narrative Report wording to say 'relationship' instead of 'married'.

BTW: Many products do now support same sex partners, but some use a different method to FH and catered for by Export Gedcom File.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Civil Partnership

Post by ColeValleyGirl »

From the FH help file:
The Status field should normally be left blank. It is used to record non-default status information. You are encouraged to treat 2 individuals who never married as if they were a married couple if:

(a) you wish to record the fact that, although they never married, they are or were a couple

(b) they had one or more children together

If you wish to record the fact that, although they never married, the ‘spouses’ were a couple, you should set Status to “Unmarried Couple”. Sometimes individuals have children without ever having a serious relationship as such. You should handle these cases using the catch-all “Never Married” value.

Where a couple divorced and then remarried, or separated and then got back together, you can record these events in the Facts tab. But the Status field should be left blank (i.e. the default) in these cases as it represents the final or last-known status of the marriage or relationship.
So yes, I stand corrected : the status indicates the (legal) (final) status of the relationship (not the marriage event as I wrote in error) -- and is associated with the family record not the marriage event. However, that seems to me to make it even more important to record the Civil Partnership status (even if also using your clever template to document the ceremony.).

Also
Only when there is no Marriage Event does the Status of Unmarried Couple or Never Married affect the Narrative Report wording to say 'relationship' instead of 'married'.
That may be true, but those of us benighted souls who don't ever use narrative reports are very used to seeing in an individual report a Marriage section that says (for example)
Marriage
Spouse Bilbo Baggins
Status Unmarried Couple
Marriage 18 Sep 1954 (age 26) Acocks Green, Birmingham, England
St. Mary's Parish Church
I know the example doesn't make sense, but if there was a Civil Partnership status, I could have:
Marriage
Spouse Bilbo Baggins
Status Civil Partnership
Marriage 18 Sep 1954 (age 26) Acocks Green, Birmingham, England
St. Mary's Parish Church
And if I change the label on the Marriage event, I could get:
Marriage
Spouse Bilbo Baggins
Status Civil Partnership
Ceremony 18 Sep 1954 (age 26) Acocks Green, Birmingham, England
St. Mary's Parish Church
(Default text ceremony would be enough for my purposes, but it makes the fact tab look odd, so I might want to do something with Override templates for the Facts tab as well).

And of course I'd add a note with any specific details of the ceremony where relevant -- such as religion, by banns or by licence.

I'd still like to lose the "Marriage" header on that section -- or rather, set it to "Relationship" but that customisation isn't possible in FH so if I have to have it the change, I can always post-process the report output.
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

OK, you can achieve that Status effect now by using a labelled Note as I suggested as an option earlier :-
Labelled Fact Note where the label is Status: or Ceremony: i.e. the usual meta-field approach.
In ISR that appears under the Marriage fact as say Ceremony: Civil Partnership along with any other labelled notes.
BTW: The Cause: Civil Partnership alternative that I proposed also appears there.
You can change the heading to Partnership but you lose the numbered suffix when more than one partnership/marriage.
i.e. Report Options > Format > Heading > Marriage > Edit > Heading Text: Partnership
Or if you set it to Heading Text: Partnership/{default} you get Partnership/Marriage (?) with the suffix.

Those that want to customise the Sentence Template can use :-
{=CombineText( "entered a ", GetLabelledText( %FACT.NOTE2%, "Ceremony: " ), " with", "married" )}

To customise the Facts tab Override Template you can use :-
{=CombineText( "", GetLabelledText( %FACT.NOTE2%, "Ceremony: " ), "", "Marriage" )}

I don't like the idea of having a Status of Civil Partnership qualifying the Marriage Event.
As the FH Help says, the Status "represents the final or last-known state of the marriage or relationship".
So if a Civil Partnership couple separate the Status should be Separated, which upsets your apple-cart.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Civil Partnership

Post by ColeValleyGirl »

To summarise where I think we've got to on this (please correct me if I've got anything wrong) :

1. A number of users want an additional value 'Civil Partnership' for the Status field associated with a family record. For this to be implemented properly (i.e. reflected consistently through the database/reports etc.) it would need to be accompanied by changes to data entry/reporting/display of the Marriage event (to reflect the different ceremony involved) or the creation of a new Civil Partnership event. (I'm guessing the easiest approach will be to vary the standard Marriage Event based on the family Status).

A Wish List request should be created for this.

[Do we need any other values for Status at present? Civil (Register Office) Marriages have existed for some time -- since 1837 in the UK for example and 1792 in France - and I haven't heard that the current Married status/Marriage event don't adequately cater for those. So my feeling is that only state-sanctioned relationships that explicitly aren't marriage need to be catered for, but I'm happy to be informed otherwise.]

2. A number of approaches exist in the interim to include information about Civil Partnerships. The viability of these depend on how quickly [we expect] Calico Pie [to] respond to the wish list and also on the volume of Civil Partnerships we have to handle (I'm assuming this will be relatively low, compared to standard Marriages, at least for some years).

a. Accept the default status of 'Married' (or any other status that seems appropriate) and use the 'Marriage' fact to record information about the Civil Partnership ceremony; qualify either the Family record or the Marriage fact with a comment identifying that Civil Partnership was the reality.

This is probably the simplest interim solution to implement, and will not impact the effectiveness of existing queries/plugins etc. but may not look good in reports.

Families affected could be easily identified by a query if and when Calico Pie implement the wish list request, so that updates can be carried out to use the new status etc.

b. Accept the default status of 'Married' (or any other status that seems appropriate) and create a custom 'Civil Partnership' event to record information about a Civil Partnership ceremony.

This should be fairly straightforward to implement (especially if SKS creates a suitable 'recommended' fact to be downloaded from the Knowledgebase) and should allow all variants of reports to look OK.

However, queries plugins etc. that use expressions involving Marriage events will overlook these Civil Partnership events, and so work on an incomplete set of data. This issue could be mitigated to some extent by the availability of a 'recommended' custom Civil Partnership fact that could be targeted by developers of queries, plugins etc. for the use of others. (Even better, the Knowledgebase could include some sample queries that take into account both Marriage and Civil Partnership events to show how it can be done by people developing their own queries.)

Families affected could be easily identified by a query if and when Calico Pie implement the wish list request, so that updates can be carried out to use the new status etc.

c. Accept the default status of 'Married' (or any other status that seems appropriate) and customise the standard Marriage Event, either on a case by case basis or globally (which has the advantage that you don't have to remember any special handling when you enter a new Civil Partnership).

Mike Tate has documented some customisation options at viewtopic.php?f=43&p=77765#p77719 and at viewtopic.php?f=43&p=77765#p77742. These depend on either repurposing another field (Fact Cause, Family Custom ID) or using a Labelled Fact Note to record the Civil Partnership status. (I'm guessing you could also add the family records concerned to a Named List and test for membership of that to customise sentences etc. but Mike will correct me if I'm wrong; using a Named List enables you to avoid repurposing fields or creating notes that may show up unwelcome in some reports. Oh, for the ability to add Flags to Family Records...)

(This approach still doesn't allow a status of 'Civil Partnership to be displayed in an Individual Summary Report in the same position as all other statuses are displayed, but that's a minor irritation unless you depend on the order of certain elements for automated pre-processing; having the associated event/ceremony displayed as Civil Partnership would probably be enough for me but others may differ).

This approach allows all queries, plugins etc. that involve Marriage events to continue working unchanged, and does not require future developers to take onto account a custom Civil Partnership event until/unless Calico Pie introduce one.

Families affected could be easily identified by a query or membership of a Named List if and when Calico Pie implement the wish list request, so that updates can be carried out to use the new status etc.

[Mike, if we can finalise this as a set of options with pros and cons, would it be worth creating a Knowledgebase page on "Options for handling Civil Partnerships", with associated templates and downloads? Not sure which section it would fit in, so maybe we need a section on "Solutions to common problems?2 which could be extended to address other things that have been thrashed out in the forums but may not be easy for users to find. Another example would be viewtopic.php?f=32&t=13121 for handling non-image media, and I'm sure we could find other examples.]
User avatar
PeterR
Megastar
Posts: 1135
Joined: 10 Jul 2006 16:55
Family Historian: V7
Location: Northumberland, UK

Re: Civil Partnership

Post by PeterR »

There was a 2009 Wish-List item similar to this. See: Minor Addition Required (6259)
Peter Richmond (researching Richmond, Bulman, Martin, Driscoll, Baxter, Hall, Dales, Tyrer)
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

In response to Helen's points :-

1. Apart from the OP (who has not replied to say if the alternatives offered are acceptable), only Helen has requested an additional Status value. So I am not enthusiastic about creating a Wish List entry, for that and the following reasons.
This Status only adds a specific Civil Partnership value, whereas the other solutions cater for any partnership ceremony.
Also it changes the semantics of Status that currently does NOT impact the Marriage Event(s).

2.
a. This solution caters for any partnership ceremony, not just Civil Partnership.
b. This solution like Status also only caters for Civil Partnership and must be replicated for any other ceremony.
c. This is just tactics for solution a. and has the same benefits.
(A Named List is not so flexible as it must have predefined ceremony name, whereas my other solutions allow the ceremony to have any name without any changes to the customisation.)

[Yes, I was contemplating a KB page on this Civil Partnership topic.
Doesn't most of the KB offer "Solutions to common problems"?
The non-image media is already covered by how_to:v4:adding_multimedia|> Adding Photographs and Other Multimedia and now has a cross-ref to the Plugin for web sites, which the topic you quoted is specifically about.]

Peter refers to Wish List Ref 399 Editable marriage status drop-down list which was dropped due to objections, that include the very valid point about potential multiple Marriage Events. This relates to my point about semantics in 1. above, i.e. which Marriage Event does the Status refer to? However, it does mention the fact Descriptor that could also be used to qualify each Marriage Event although that does not appear in ISR, but also does not appear in other reports, so can customise the Narrative Sentence similar to the other options without side-effects.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Civil Partnership

Post by ColeValleyGirl »

Mike

Re 1:
Apart from the OP (who has not replied to say if the alternatives offered are acceptable), only Helen has requested an additional Status value. So I am not enthusiastic about creating a Wish List entry, for that and the following reasons. This Status only adds a specific Civil Partnership value, whereas the other solutions cater for any partnership ceremony.
You cannot take silence as agreement or disagreement -- that's what the voting facility on Wishes is for; your personal enthusiasm as a gatekeeper is immaterial. There is no alternative solution proposed here which simply implements a 'Civil Partnership' status on a Family Record consistent with other Family 'Statuses', so the request should be created. [For the record, I don't need it but do think it should exist -- for consistency, and to aid customisation if it's required.]
Also it changes the semantics of Status that currently does NOT impact the Marriage Event(s).
That's why I said there would also have to be changes to the Marriage Event or the introduction of a Civil Partnership Event.

Re 2:
a. This solution caters for any partnership ceremony, not just Civil Partnership.
b. This solution like Status also only caters for Civil Partnership and must be replicated for any other ceremony.
c. This is just tactics for solution a. and has the same benefits.
(A Named List is not so flexible as it must have predefined ceremony name, whereas my other solutions allow the ceremony to have any name without any changes to the customisation.)
Points noted; and they should be included in any Knowledgebase entry as part of the pros and cons to allow individual users to select their approach.

Re
Doesn't most of the KB offer "Solutions to common problems"?
Which existing section do you see it going under? I can't see an obvious option to ease structured navigation for this.

Re
which Marriage Event does the Status refer to?
The last, according to the FH help, which I've quoted elsewhere in this topic.

Re
the fact Descriptor that could also be used to qualify each Marriage Event although that does not appear in ISR, but also does not appear in other reports, so can customise the Narrative Sentence similar to the other options without side-effects
Good spot -- this could be the best way to go as an interim; the Descriptor enables customisation of sentences/fact tabs/labels etc. without side-effects; KB will have to remind people how to access it to set it.
User avatar
PeterR
Megastar
Posts: 1135
Joined: 10 Jul 2006 16:55
Family Historian: V7
Location: Northumberland, UK

Re: Civil Partnership

Post by PeterR »

The GEDCOM Standard includes:
The MARR tag could be subordinated with a TYPE tag and EVENT_DESCRIPTOR value of Common Law. Other possible descriptor values might include "Childbirth--unmarried," "Common Law," or "Tribal Custom," for example. The event descriptor should use the same word or phrase and in the same language, when possible, as was used by the recorder of the event. Systems that display data from the GEDCOM form should be able to display the descriptor value in their screen or printed output.
I think "Civil Partnership" would be as reasonable as "Common Law" or "Tribal Custom".
Peter Richmond (researching Richmond, Bulman, Martin, Driscoll, Baxter, Hall, Dales, Tyrer)
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

Well spotted Peter.
So Gedcom already allows for customisation of the Marriage Event via its Descriptor (TYPE) subordinate tag.
That can be used to customise Sentence/Override Templates now.

The only feature missing is adjustment of non-Narrative Reports for the Marriage Event to include the Descriptor value.
So a generalised Wish List request could be for some way of including Descriptor values in non-Narrative Reports such as the Individual Summary Report and Family Group Sheet.
Perhaps there should be an Option to replace the fact Label with the Descriptor when it exists.
That option could be in the Report Options, but may be better in the Tools > Fact Types definition.
This would appear to be a very elegant and generic feature with lots of potential uses way beyond Civil Partnership for Marriage Events, and is fully Gedcom compatible.

The Descriptor is far superior to the Status proposal that only allows one specific value (Civil Partnership) and overlooks all the other possibilities such as Common Law or Tribal Custom, etc. Unless that is the Status proposal suggested full customisation of the Status values, with all their potential semantic consequences on Facts (Marriage Event) and Reports, which sounds rather complex.
Helen, if you still really want it, then I could reinstate Wish List Ref 399 Editable marriage status drop-down list with an update to this posting.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
ColeValleyGirl
Megastar
Posts: 5465
Joined: 28 Dec 2005 22:02
Family Historian: V7
Location: Cirencester, Gloucestershire
Contact:

Re: Civil Partnership

Post by ColeValleyGirl »

The Descriptor might be a good multi-purpose solution for rare/bespoke customisation requirements (avoiding the need to repurpose other fields), and for interim solutions in parallel to creation (and hopefully implementation) of a wish list item. However, I don't think it's appropriate as a long-term solution for a routine (if non-default) requirement like a Civil Partnership, for the reasons outlined below. (As an aside, I wonder if Civil Union is a more widely-applicable term than Civil Partnership?)

Descriptor versus Status

1. Simplicity and Consistency of Data Entry

If Civil Partnership is included in the list of possible Statuses, recording a Civil Partnership is as easy as setting the Status (Main tab of the property box) and (if details are known) creating a Civil Partnership event. If no details of the ceremony are known (in which case, some genealogists won't create an event for the ceremony), this approach still enables recording the Status and (very important) associating a Source Citation with that Status.

Customisation requirements for data entry (once the Civil Partnership status is available) : creating a custom Civil Partnership event (only necessary if Calico Pie don't include one in the Extended Fact Set).

As an approach, this if fairly intuitive -- a new user could work out what to do without having to refer to (e.g.) the Knowledgebase or help file for guidance, once they know how to enter a marriage (say).

Using the Descriptor requires either customisation of the Property Box to make the Descriptor easily accessible (which could be challenging if you need to access the Descriptor on multiple events) or navigating to the relevant place in the All tab and adding the field there. Neither of these alternatives are easy for inexperienced users; even if they were, it would hard to articulate convincingly (other than in technical terms) why a different approach has been taken for Civil Partnerships compared to other Statuses.

Using the Descriptor also requires customisation of the Marriage Event; and you have to create a Marriage Event to use the Descriptor -- which means you would have to create a Marriage Event purely to act as a proxy for the Status value even if you have no information about the event. The most severe drawback IMO is that you can't associate a Source Citation with the Descriptor (only with the Marriage event).

2. Consistency of Querying, Reporting, Diagrams etc.

a. The Status field is used to modify the Display of the lines between two 'spouses' in diagrams; adding a Civil Partnership value could require Calico Pie to include Civil Partnership in the list of Marriage status line options (or they could simply document that the default Marriage lines also apply to Civil Partnerships). It might also be necessary to customise text schemes to include Status and/or Civil Partnership events. Similarly, text scheme customisation mightbe required to include the Descriptor value (or customised Marriage details).

b. Queries, plugins etc. would have to be modified to take a new Status value into account, where they depend on the Status field. Where they depend on the existence of a Marriage Event, there's already a potential issue in that they won't pick up marriages for which no Marriage Event has been created.

Using a Descriptor to customise the standard Marriage Event would probably have less impact on existing queries and plugins, but they might need to be modified anyway to query or display the Descriptor value.

New queries and plugins could be constructed using either approach, but might be simpler for beginners if they used the Status field. Experts will have no problem with the Descriptor.

c. Using the Status field would enable all existing reports to be used with a minimum of changes (the Civil Partnership status value would show up where existing status values do now, but any custom Civil Partnership Event might have to be included in the facts shown).

Using the Descriptor would mean that the Civil Partnership 'marker' showed up in a different place from 'ordinary' status information in non-narrative reports, which would be hard to explain to individuals who see (and might be insulted by) the variant treatment of their own relationship (likewise of they see it misrepresented as a kind of relationship that is isn't). It would also cause problems for automatic post-processing of reports but I suspect that's a very rare requirement, so it isn't a killer issue.

3. Extensibility

Using the Descriptor would handle unforeseen requirements and/or user specific preferences, and doesn't depend on Calico Pie once the underpinning mechanisms are in place.

Adding a Civil Partnership Status would recognise a genuinely new (well, relatively new -- some countries have had them for nearly 30 years now) form of relationship (rather than a variation on an existing form), but the addition of another Status would means another piece of work by Calico Pie.

4. Gedcom compatibility and data portability.

Status (_STAT) is already a custom FH Gedcom extension; adding another value doesn't alter that (or affect its portability).

Descriptor is a standard Gedcom field but research would be needed to ascertain how it is used/displayed in other programs to determine how portable it really is.

What about an editable marriage status drop-down list?

Maybe... but it has signicant problems due to the amount of work a user would need to do to implement a new status comprehensively.

It would remove any dependency on Calico Pie to support new values, but without complicating data entry (too much). A user could create a custom event associated with a new value, but it wouldn't be essential if (for example) they're just distinguishing between different forms of Marriage and the standard Marriage Event does the job they need. [I wouldn't recommend customising the Marriage Event based on Status; Status records the last (known) status for the relationship, and if for example a couple had multiple ceremonies followed by a divorce, you would not want all the marriage events to reflect the divorce status. Advanced users might find the Descriptor useful in this context; a simpler approach to suit narrative reports would be to edit the fact sentence on a case-by-case basis, or to fall back to Notes for summary reports).

Users who added values would have to understand that there'd be no option to configure the associated 'marriage lines' in diagrams, so text schemes would have to be modified to display the Status value if that was important to see.

They would also have to understand that standard queries, plugins etc. would not handle their custom statuses/events "out of the box" and it would be their problem to modify them.

Reports might need modifying to include any new custom event associated with the new status value...

And the more statuses/custom events, the more work to do; it's not something that should be done lightly.

The IT purist in me also suspects that the ability to create new statuses would result in Status being used for a mix of true relationship statuses (Unmarried couple) and research statuses (Marriage not found yet), which makes me uncomfortable but others may not care.

My conclusion:

Civil Partnership is a routine data entry/display requirement. We should have a standard Civil Partnership Status value, supplemented with a Civil Partnership Event (which could be part of the Extended Fact Set). Some users may choose instead to customise the standard Marriage Event, but that doesn't satisfy all the requirements that Status meets.

An editable marriage status drop-down list might be of value but could lead new users into problems thay haven't anticipated. Alternative approaches are available to intermediate/advanced users to distinguish between different forms of a single status. For new users, I suspect the complexity of what would be needed to implement a new status value consistently would outweigh any value and they should be steered towards morestraightforward techniques first.

The Descriptor lends itself well to being the basis for a wide range of rarer data entry problems, if data entry can be made as simple as possible and the reporting limitations overcome.


So: 2 wish list requests required, one for a Civil Partnership/Union Status and associated event; and one to make the Descriptor more useful for Marriage events by adjusting some reports (and the Fact Tab for data entry?). Or should it be extended to cover other events for which a descriptor exists -- it seems quite widespread ? I don't support reopening the editable marriage status request.
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Civil Partnership

Post by AdrianBruce »

ColeValleyGirl wrote:... If Civil Partnership is included in the list of possible Statuses ... If no details of the ceremony are known (in which case, some genealogists won't create an event for the ceremony), this approach still enables recording the Status and (very important) associating a Source Citation with that Status. ...
I think this is an important point. However, I am perturbed by the possibilities. Should one have, say, a "Divorced Civil Partnership" Status, say? And if not, why not? Logically, in sort-of-scientific terms, Civil Partnership or conventional marriage is one dimension and whether terminated formally (Divorce) or informally (Separated) is another dimension.

All this starts getting sticky in terms of clarity - I'd offer the cautionary tale of Family Search Family Tree, which has attempted to replace the concept of Family by Spousal Relationship and 90% of its users are baffled because they keep interpreting Spousal Relationship as Family and / or Marriage.
Adrian
User avatar
tatewise
Megastar
Posts: 28344
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Civil Partnership

Post by tatewise »

If Civil Partnership is included in the list of possible Statuses, recording a Civil Partnership is as easy as setting the Status (Main tab of the property box) and (if details are known) creating a Civil Partnership event. If no details of the ceremony are known (in which case, some genealogists won't create an event for the ceremony), this approach still enables recording the Status and (very important) associating a Source Citation with that Status.
Whether details are known or not, creating a Civil Partnership Event is all that is needed, and the Status is unnecessary.
It is not clear to me why both are required.
Rather than simplify, I think it complicates things for novices, by making it a special case not applied to any other Events.
If there is a genuine need for a Status value of Civil Partnership, then why not also a Status value for Engagement, Marriage, Annulment, etc, etc, for all the same reasons?

I don't believe it is possible to associate a Source Citation with the Status value, but only with the whole Family Record.

If the couple are later Separated or Divorced and recorded in the Status, then the Civil Partnership value is lost.
My fundamental concern is with the semantics of this Status approach to recording what are actually Events.
Status = Divorced is NOT an Event but a Diagram line control.
Status = Separated pre-dates the Separated Event in the Extended Set and should be deprecated.
All other Status values record the state of the partnership NOT an Event (and perhaps would be better as an Attribute).

The Descriptor (TYPE) tag does apply to all standard Events and Attributes and a Wish List request would apply generically to add Descriptor as a Facts tab field with {descriptor} as a Template Code and Report Options. For some particular cases such as Marriage Events the default Templates, Report Options and Text Schemes would support such Descriptor values, and drop-list values provided for such as Civil Partnership. (This is used elsewhere to offer drop-list values, but any value can be entered by hand.)
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
Post Reply