* Type of personal name

[AdrianBruce]

Requirement: Family Historian should be able to record a 'type' against an individual's personal name.

Further, it should provide the ability to show this in a diagram text scheme AND in reports such as the Narrative Reports, Family Group Sheet, Individual Report, etc.

Reason: When women are married twice but their birth surname is not known, I am tending to record at least the first married name as an alias. Without doing this, reports and diagrams show only a first name, which is of no help in distinguishing the person. If I do record the first married name as an alias, I can make it appear in diagrams but if the first husband is not on the diagram, it is not apparent why that name is there.

Possible way forward: GEDCOM 5.5.1 introduced the concept of a NAME_TYPE. The tag (TYPE) is subsidiary to the person's NAME and takes these values:

• aka = also known as, alias, etc.
• birth = name given on birth certificate.
• immigrant = name assumed at the time of immigration.
• maiden = maiden name, name before first marriage.
• married = name was persons previous married name.
• user_defined= other text name that defines the name type.

There is a need for user defined types - I can think of 'stage name', and maybe '1st married', '2nd married'.

FH could therefore implement this as a custom tag _TYPE with the same values, in the same place, assisting any conversion to / from a GEDCOM 5.5.1 file.

ID:6665

[PeterR]

I think most of us record the birth name as the surname for married women, which would make the Type value 'maiden'  redundant.

The definition of Type value 'married' as 'name was person's previous married name' seems to imply that the current (or last, if more than one) married name would be recorded as the main Name but without any qualifying Type which, I think, many of us would find at odds with normal practice.

Otherwise I would be more than happy to support this request.

[tatewise]

Individuals can be given as many Name instances as desired, i.e. NAME[1], NAME[2], NAME[3], etc.

Any or all of these Names can be included together in Diagrams, in Queries, in most Reports, and elsewhere.

Also you could conventionally use the Prefix or Suffix or Nickname field to hold a Type designation for each Name instance, and include it in Diagrams and Reports.

[PeterR]

Currently in GEDCOM 5.5 and in FH, each Name can also have a Note which could hold the same values as proposed for Type.

[RogerF]

I'm sure Adrian is perfectly well aware of FH's capabilities for multiple Name fields, and for Note fields. What he's asking for goes beyond that -- a formally-defined way of classifying the contents of a Name field, such that it can be consistently processed. Sounds pretty sensible to me.

[Cambiz]

Wishlist No 520 has been added for this.

Please vote on it here:

http://www.fhug.org.uk/wishlist/wldispl ... lwlref=520

[AdrianBruce]

Peter - re 'most of us record the birth name as the surname for married women, which would make the Type value 'maiden'  redundant.'
Usually - yes. But if we define 'maiden' as name before marriage, it is possible that the bride has changed her name due to adoption, etc., between birth and marriage, so in such circumstances, it's not actually redundant. The type would clarify which name was which, especially if the diagram is not centred on her so doesn't show her other husbands.

Re 'married' as defined in GEDCOM 5.5.1. That's one I'm not too happy with anyway because its use is not clear for multiple marriages. Hence I'd not really thought through the implications of 5.5.1's definition. Hence my suggestion of the continuing need for user defined values. Or Simon could add '1st married', etc, to the FH list.

And re the note having the type values. Well, yes, but try and get those notes printed anywhere.... In any case, if I want to make it appear on a diagram, I'd want to separate the short 'type' note from the longer dissertation note.

Tatewise - Certainly all the names can appear on diagrams. I have it thus now. But it was the case where a list of 2 or 3 names appears with no clue why (because the husbands aren't shown) that led me to this suggestion. And, yes, I could indeed put the type into the prefix, etc, but I'm sure you can guess that many people, myself included, would regard this as a misuse.

[tatewise]

I accept that the suggestion has merit and that using Prefix, etc would be a misuse.

However, I have experimented with the Note fields, and have no problem displaying the details in Diagram Boxes and in most Reports.
(The exception being Narrative Reports, which have known problems with showing multiple Names, etc.)

Two techniques seem feasible:

(1) Labelled Note Text
Here the Name Type is prefixed with Type: and the Dissertation is prefixed with Note: within the Note field.
Then =GetLabelledText(%INDI.NAME[n].NOTE2%,'Type:') can be used in Text Scheme > Item > Templates or added to Report Options > Contents > Main Items to show the Type.
While =GetLabelledText(%INDI.NAME[n].NOTE2%,'Note:') would show the Dissertation.
A snag with this technique is that the Dissertation must all be in one paragraph.

(2) Multiple Note Fields
Here the Name Type is entered in the 1st Note field, and the Dissertation in the 2nd Note field (or vice versa).
Then %INDI.NAME[n].NOTE2[1]% can be used in Text Scheme > Item > Templates or added to Report Options > Contents > Main Items to show the Type.
While %INDI.NAME[n].NOTE2[2]% would show the Dissertation.
The snag with this technique is that to add a Dissertation in NOTE2[2]%, there must be a Type in NOTE2[1]%, but this can be a single space character.

[ColeValleyGirl]

A date (including date range) would also be invaluable for different names/types of name.

[PeterR]

I agree with Helen about the desirability of Date as an attribute of Name; the related attribute Title already has Date, etc.  I think this lack has prompted the definition of a Custom Event (with Date, etc.) for Change of Name.

[AdrianBruce]

Peter - Date would indeed be welcome as an attribute of Name. It can be used for all sorts of cases where a Type would be an artificial construct, though conversely a Type could provide a clear 'reason' for the change, where one exists.

However, one reason for my suggestion of Type is that it's there in GEDCOM 5.5.1 so might seem a more attractive option to Calico Pie, rather than a completely new tag.

As an aside, FamilySearch seems for some strange reason, to have set its face against having a date against name as even GEDCOMX, their latest idea, didn't have it. Almost as if they thought Name should only ever contain a birth name and the rest could be generated.

[AdrianBruce]

Mike - thanks for that reminder about GetLabelledText. On reflection, that method looks quite interesting.

Thanks also for the warning about multiple names in narrative reports. I keep wanting to use narrative reports, and they keep falling short - primarily because the sentence construction needs to allow any tag values to be picked up - like queries do.

[PeterR]

I found the following in The GEDCOM X Conceptual Model

3.13 The 'Name' Data Type
...
date      The date of applicability of the name.      ...      OPTIONAL.
...

[tatewise]

Adrian, regarding 'multiple names in narrative reports', FYI my Adjust AKA Names for Reports plugin offers workarounds for this problem.

I don't understand your complaint about Narrative Reports: 'the sentence construction needs to allow any tag values to be picked up - like queries do.'

[AdrianBruce]

Mike (belated reply)
Re - Narrative Reports: 'the sentence construction needs to allow any tag values to be picked up - like queries do.'

The template sentence for a fact definition only allows insertion of a small number of codes. While it covers the main ones, there are missing ones - the one that always bugs me is the omission of Responsible_Agency, since that's where I put the employer's name in an occupation. Unless and until all such codes appear in the construction of template sentences, then narrative reports are crippled in the proportion of the missing tags.

[tatewise]

Ah, Yes!
This is covered by WL 357: Allow sentence templates to accept data expressions and functions.

It would be so much easier for users if the same Template Codes, Data References, Functions, and Expression concepts were applied consistently and comprehensively in all relevant places.
e.g. Sentence Templates, Report Items, Diagram Text Schemes, Diagram Box Conditions, Query Columns, Record Window Columns, Property Box Captions, Property Box Custom Tabs.

This is mostly already in place, but there are a few notable exceptions.