* On Hold until 13 Dec 2024: Dating and Usage of Names and Alternate Names

[davidf]

Where individuals are known by different names at different times, there is a need to be able to record effectivity dates of the alternative names.

Additionally it would be useful to be able to associate specific alternative names with specific facts.

(This arose from the thread Names and Name Changes over time)

Requirements:
1) Implementation of %INDI.NAME[1]._DATE% in a similar manner to %INDI.TITL[1].DATE%
2) Ability to associate a specific name with a specific fact.

Notes:
1) There is a similar structure in FH (and GEDCOM) for titles; a custom Date tag would allow similar for names.
2) FH already does similar linking through the custom _ASID tag (as seen for instance in linking an area in an image to an individual's record - and probably elsewhere as well)

Reference in the Individual record: note the _ASID subfield to the Object tag (bottom line)

Link in INDI record to an Image area in an Object Record

Screenshot from 2022-11-06 16-36-55.png (11.54 KiB) Viewed 3932 times

Reference in the Object Record: note the corresponding _ASID subfield to a NOTE in the Object (Media) record). If an image (say a group image) has multiple image areas linking to different people, this NOTE structure is repeated with a different value for _ASID.

Back link in an Object record to an INDI record

Screenshot from 2022-11-05 17-42-24.png (12.84 KiB) Viewed 3932 times

The only difference would be that the "link" would be referring back to the same INDI record.

[davidf]

Bump as part of the Blitz of Wish List Requests - with updating and formatting of request:

Dating and Usage of Names and Alternate Names

Requirement

1. Where individuals are known by different names at different times, there is a need to be able to record effectivity dates of the alternative names.
2. Additionally it would be useful to be able to associate specific alternative names with or resulting from specific facts.
3. Where there is not a fact specific name, user code availability to enable reports to use "Current Name" - the name at the time the event being reported actually occurred (or immediately prior to it if the event was a name changing event).

Benefit
Sentences and reports could use the name by which the person was known at the time of the event (or immediately prior to it if the event was a name changing event). At the moment it looks strange, for instance, to report that the "death was notified by Sarah Smith", when in fact at the time she was married and was called and signed as "Sarah Jones".

Notes

1. Implementation might be possible by %INDI.NAME[1]._DATE% in a similar manner to %INDI.TITL[1].DATE%
2. Ability to associate a specific name with a specific fact could follow previous use of _ASID and _SEQ tags
3. In designing the implementation care will have to be taken to ensure (via NAME.TYPE?) that if a woman had a birth name, name by adoption, a married name (official sequence of names) and a stage or pen name (professional names), that the later is not used in normal reporting.
4. In designing the implementation care will need to be taken to detect whether it is the name immediately prior to the event that should be used, or the name consequent on the event. (For instance you would use the bride's maiden name (name immediately prior) in a marriage report not the married name she acquired as a consequence.

Discussion Threads
Names and Name Changes over time (21126)
arising from
Data reference for witness (21122)
Note also AS requirement
Witness name on a marriage (21297)

Annex: linking to Specific Facts
FH already does similar linking through the custom _ASID/_SEQ tag (as seen for instance in linking an area in an image to an individual's record - and probably elsewhere as well)

Reference in the Individual record: note the _ASID subfield to the Object tag (bottom line)


Reference in the Object Record: note the corresponding _ASID subfield to a NOTE in the Object (Media) record). If an image (say a group image) has multiple image areas linking to different people, this NOTE structure is repeated with a different value for _ASID.


The only difference would be that the "link" would be referring back to the same INDI record.

[AdrianBruce]

...
- In designing the implementation care will have to be taken to ensure (via NAME.TYPE?) that if a woman had a birth name, name by adoption, a married name (official sequence of names) and a stage or pen name (professional names), that the later is not used in normal reporting.
...

Did I miss why the stage / pen-name shouldn't be used specifically for women? I'd imagine that if it were thought odd to use a stage-name for a woman, it was equally odd to use it for a man?

To some extent, I'm not entirely convinced that stage / pen-names shouldn't be used for normal reports. To take my go-to example of Archibald Leach, he legally changed his name to Cary Grant in 1942 when he naturalised as a US citizen. So, strictly speaking, that would be two instances of the name "Cary Grant" - the first as a stage-name from Dec 1931 to 1942, the second as a "proper" alternate name from 1942 on. But references to him in Hollywood pre-1942 might then seem odd if they continually mentioned "Archibald Leach".

Frankly, I suspect that the whole thing may be a matter of taste - and the ability to ignore the dictum that the primary name should be the birth name. Suppose we do have the rule in place that stage-names don't over-write "proper names". Then if you want reports on Cary Grant to use "Cary Grant" as his name, just make it the primary name, with Archibald Leach as an alternate (with a type of birth name?) and Cary Grant as a stage-name from 1931. (After all it was his stage name for the rest of his life - it just happened to match his real name from 1942 on).

And if you'd prefer that your reports mentioned John Lydon, rather than Johnny Rotten, then keep Johnny Rotten as his stage-name, inhibited from appearing in reports by the rule that stage-names don't over-write "proper names".

[AdrianBruce]

On reflection, since there is an OTHER value for NAME.TYPE, maybe the proposed logic about not overwriting the Primary name in a report by the current Stage Name, should be removed and replaced with a new custom field that indicates whether this particular name of any type should or should not be allowed to replace the current name in a report.

Then I could set Cary Grant's Stage Name to Replace In Reports = Yes to show that name in reports during the currency of the Stage Name.

Conversely, I could set the Stage Name of Johnny Rotten to Replace = No to ensure that reports always showed John Lydon in the reports.

Adding that extra custom item saves the necessity of encoding rules of replacement in the software and allows Other to be handled as you, the user, define.

[davidf]

Did I miss why the stage / pen-name shouldn't be used specifically for women? I'd imagine that if it were thought odd to use a stage-name for a woman, it was equally odd to use it for a man?

That was not my intention! I was trying to think my way around if say "Emily Jane Brontë" had taken the pen name "Ellis Bell", and then got married, I would want the sentence to say "Emily Brontë married ...", and not "Ellis Bell married ...".

Clearly there is some complexity to trash out. So!

I was trying to imply that an implementation of this needed to recognise:

• "time-line names" (the official name - generally used when referring to a person at an event or acquiring an attribute) and,
• "supplementary names" (used in specific circumstances - such as stage and pen names)

If you chose to use a sort of NAME[Current] structure (however CP decides to implement it), I would anticipate that you would look for a "time-line" name - being a %INDI.NAME[n]% & %INDI.NAME[n]._DATE% taking the name that was current at the relevant date - subject to:

• If time line dates overlap on the fact date (possibly due to user error), the date used is the one with the latest start date, except,
• If a date ends on the fact date and another starts on that date (as might be legitimately expected for instance on marriage), the ending date (e.g. the expiring maiden name) is used.

To ensure that "time-line names" are used in such circumstance in preference to "supplementary names" either:

1. the %INDI.NAME[n].TYPE%* has to Indicate "TLN:" and "SN:" before any narrative - which whilst being language specific, is I think preferable to a two level type construction which is unlikely to become GEDCOM standard, or
2. any dated %INDI.NAME[n]% is treated as a "time-line name".

* There is a type "user_defined= other text name that defines the name type" (p56 of ged551.pdf).

If the latter option is selected "Supplementary Names" would be undated names associated with specific facts. The sentence construction could be something like "[Primary Name|Current Name] published his book "[Value]" (as [Fact Associated Name])"

My inclination is to associate a fact with a name through some linking mechanism (_ASID/_SEQ).

The alternative is to actually enter the Supplementary Name as a custom sub branch of the Fact (say FACT._NAME). Even that could be avoided by ensuring that your "Published" and "Appeared in" Facts had [["Pen Name: "]] & [["Stage name: "]] in a structured fact note and have "=GetLabelledText()" put the relevant name into the sentences.

[AdrianBruce]

1. The distinction between Time-Line-Names and Supplementary names sounds good.

2. Not keen on saying that

any dated %INDI.NAME[n]% is treated as a "time-line name"

because I might want to provide a date for the name "John le Carre", etc...

3. The idea of TLN requesting a Time-Line-Name, etc, seems OK - but still avoids the issue of how to define in the GEDCOM file, which are TLN names and which SN names. Any list of name types that FamilySearch comes up with, will omit some cultures, guaranteed. For instance, that list doesn't include names acquired when reaching adulthood (e.g. the difference between "Sitting Bull" and "Jumping Badger" - I'm relying on Wikipedia there and obviously I've written it in English...). Adulthood-Name would be a TLN, whereas I might also want to create a name type of "Nom-de-guerre", which would be a SN. Both would be dated.

4. I would prefer to avoid Labelled Text in any "proper" solution - not least because I have no confidence that it's well understood.

[davidf]

1. The distinction between Time-Line-Names and Supplementary names sounds good.

Yes, but we then do have to distinguish between them!

2. Not keen on saying that

any dated %INDI.NAME[n]% is treated as a "time-line name"

because I might want to provide a date for the name "John le Carre", etc...

3. The idea of TLN requesting a Time-Line-Name, etc, seems OK - but still avoids the issue of how to define in the GEDCOM file, which are TLN names and which SN names. Any list of name types that FamilySearch comes up with, will omit some cultures, guaranteed. For instance, that list doesn't include names acquired when reaching adulthood (e.g. the difference between "Sitting Bull" and "Jumping Badger" - I'm relying on Wikipedia there and obviously I've written it in English...). Adulthood-Name would be a TLN, whereas I might also want to create a name type of "Nom-de-guerre", which would be a SN. Both would be dated.

If the consensus is that we need to be able to date "Supplementary Names", I think we have to go with option 1

the %INDI.NAME[n].TYPE%* has to Indicate "TLN:" and "SN:" before any narrative

so we would have NAME[n].TYPE's like "TLN: Deed Poll Name Change" and "SN: Pen Name"

4. I would prefer to avoid Labelled Text in any "proper" solution - not least because I have no confidence that it's well understood.

I think I agree - I put it in because I thought someone would point out "you can already do this" (if you are familiar and confident with expressions, sentence construction and using "auto-create Note" to create Note Templates). If we go with option 1 that could go out the window.

[AdrianBruce]

...
so we would have NAME[n].TYPE's like "TLN: Deed Poll Name Change" and "SN: Pen Name" ...

Ah - that's OK, I didn't realise that's where you wanted TLN and SN to go...

[davidf]

If we use a prefix in the NAME.TYPE to determine the usage of names, it might be helpful to think through how it works in practice.

Setting the Option

There has to be an option somewhere as to whether reports (and other forms of output - which?) are to refer to the "Primary Name" (NAME[1]) or to refer what we might call the "Current Name" (the time-line name going into the event or attribute). Similar concerns might apply to use of "Supplementary Names". I would imagine that we might have a number of scenarios:

1. Where the user always wants to use the "Current Name" for all individuals for all facts in the project
   • This could be handled by a Project Variable - set in Preferences,
2. Where the user may want to use the "Current Name" for specific individuals for all facts.
   • This probably requires an Individual Variable - set in their property box?
3. Where the user may want to run a report using "Current Name" for all facts, irrespective of other settings (e.g. an audit report on names)
   • Where there could be a checkbox on the report setup dialog

Use of Supplementary Names

Supplementary Names could be associated with facts by a selection dialogue accessed by an icon immediately to the right of the fact in the Fact tab - in an analogous way to how media is associated with a fact. (It would be different from "Witnesses", because that creates associates with different people, whilst this creates an association between a specific fact for an individual and a specific name for the same individual.)

Is it too restrictive to say that Supplementary Names can only be used in association with specific facts? So stage or pen names might be used in two circumstances:

1. FACT _SUPN for being able to record "from date x he/she adopted NAME[association with this fact] as his/her NAME.TYPE¹
2. Facts relating to Publishing, Appearances etc. where the sentence would/could say "[Primary Name|Current Name]" appeared in "[attribute]" <using the NAME.TYPE¹, NAME[association with this fact]>².

¹ In wanting to use a value for NAME.TYPE in sentences etc., CP would have to use the value entered in NAME.TYPE having removed any prefix ("TLN:" or "SN:" etc.). I don't totally like this, but cannot see another way round this (other than a NAME.TYPE.TYPE construction - which I very much doubt will ever get into a GEDCOM standard, whilst NAME.TYPE is already there). I think this is a sort of problem that we might acknowledge (with examples of how it might be a problem), but leave to CP to sort out in their implementation.

² In this sentence I am anticipating two values within the angle brackets - which I think fails even though the two values are associated, one being the subordinate to the other. It may be that CP have to decide to code in the strings "screen name" for film type appearances, "stage name" for theatre type appearances and "pen name" for publication type appearances, etc.

Both these footnotes arise from wanting to use NAME.TYPE to distinguish between Types of Name and to hold a sentence element relating to those types.

Are there other instances where we might want to have supplementary names that may not be covered by this sort of framework?

[AdrianBruce]

...
Is it too restrictive to say that Supplementary Names can only be used in association with specific facts? ...

Just at the moment I fear that it is too restrictive.

I think that I might want to refer to Archibald Leach as Cary Grant from 1931 onwards for all facts, even though that's only a Supplementary Name from 1931 to 1942. But (thinking out aloud...) how am I invoking such a report? Would I be altering the narrative sentence for the facts in question? But based on what I just said, that's every fact from 1931 onwards.... Yuk. Am I coming back to declaring "Cary Grant" as the primary name from 1931 onwards, regardless of its legal status????

Perhaps more to the point, I can envisage user defined name types, being used against user defined fact types... E.g. Fact Type "Oscar"???

[davidf]

Am I coming back to declaring "Cary Grant" as the primary name from 1931 onwards, regardless of its legal status?

The way I have it currently specified I think you would define "Cary Grant" as a time-line name from 1931 (because you want it used from a point on the time-line). Nothing stops you setting NAME.TYPE as "TLN: Screen Name". Until you reached a date when another TL Name was current (per previous rules) it means that if "use current" was checked the name current at the time of the start of the event would be used.

(If you did that you would not then want to associate the same name as a Supplementary Name with for instance a "Film Appearance Fact" because that could give you "Gary Grant appeared in "[attribute]" using Gary Grant as his screen name". The part in italics would not appear if there was no Supplementary Name associated with the Fact.

I'm not redefining the "Primary Name" which would still be which ever one you defined as NAME[1] - I have referred to [Primary Name|Current Name] because which was used would depend on whether "use current" was or was not checked. (Unless coded otherwise the Primary Name would still be the name used in Diagrams at the "top of the box".)

[AdrianBruce]

...
The way I have it currently specified I think you would define "Cary Grant" as a time-line name from 1931 (because you want it used from a point on the time-line). Nothing stops you setting NAME.TYPE as "TLN: Screen Name". ...

Yes, that starts to make sense to me. That's where the person specific variability comes in that I wanted.

So where are we with the Supplementary Names? You seemed to be suggesting restrictions on the fact types???

[davidf]

So where are we with the Supplementary Names? You seemed to be suggesting restrictions on the fact types???

Well I was just wondering how in practice they would be used. Time-Line Names would take over from Primary Name if the option is selected, so when would Supplementary Names be used?

Use of Supplementary Names

Thinking of Stage, Screen and Pen names you would expect them to be used in association with facts relating to the Stage Screen or Publications (possibly _STAGE, _SCREEN, _PUB, etc.). If this wish was implemented it would seem logical for CP to provide such facts - which the user cannot create without changes to the Fact type edit process - because of the need to build in the ability to associate a name.

Note that for Supplementary Names, there is no reason why any type of name shouldn't be used. For instance, a women may use her maiden name as her pen or stage name. (The "SN:" prefix is technically not required; it is only the "TLN:" prefix which is needed to mark those names that should be used if "use current" has been selected).

You might also want a general fact to record when an individual started to use a Supplementary Name - "from [date], [Primary Name|Current name] used the name [Supplementary Name] as a [Supplementary Name].TYPE (less the Prefix "SN:" or "TLN:"), hence the two cases I mentioned earlier.

1. FACT _SUPN for being able to record "from date x he/she adopted NAME[association with this fact] as his/her NAME.TYPE¹
2. Facts relating to Publishing, Appearances etc. where the sentence would/could say "[Primary Name|Current Name]" appeared in "[attribute]" <using the NAME.TYPE¹, NAME[association with this fact]>².

Other types of "Supplementary Name" could use FACT _SUPN (per 1 above). The second case would require creation of custom facts following the general structure of those mentioned above.

The restrictiveness was in two directions:

1. My ability to think of other examples of names that are Supplementary Names rather than Time-Line Names
2. Creation of Facts that use Supplementary Names.

Creation of Facts that use Supplementary Names

Currently the V6 Fact Definition dialogue has the following options:

Fact Definition (V6)

Screenshot from 2022-12-15 23-30-07.png (13.81 KiB) Viewed 3076 times

For supplementary names to "work" you would need the dialogue to include:

• An additional "Fields Required" entry "Supplementary Name"
• a default sentence to use the supplementary name with appropriate sentence template code

The impact of ticking Supplementary Name, would be to introduce a means to associate a name with the fact. I have previously suggested that it could be an icon to the right of the fact in the fact tab (like the add media to fact icon). Alternatively it could be an extra field (pull down box) in the add fact dialog in the Facts tab. There would also presumably be a means to do so via the All Tab.

Ideally the "Associate Name" process would also allow "Add Name".

[AdrianBruce]

Hm. Interesting. But I'm not sure whether it's "Interesting" interesting or "Interesting Times" interesting...

I really have problems with any proposal that leads to CP providing such facts and those being the only ones that use Supplementary Names. The whole (delightful) point about user defined facts is that the user can supply their own, however mad it may appear to the rest of us.

I have also been trying to think through some uses of Supplementary Names, leading me to question how deep this aspect needs to go. (It could go deep - does it need to, though?). To take pen-names, as a concrete example.

Some might be thought so important that they merit appearing as a time-line name - John Le Carré, for instance. So long as you can switch that off (for instance, on the Death Event), we might be happy to see most references use Le Carré as his name.

Others are much more problematic, I suggest. According to Wikipedia, Dean Koontz has 10 different pen-names . I imagine that some of them could be used in parallel, as well. That certainly happens with some authors. How would one specify which name to use - and how would that specification be robust in the face of changing Alternates?

To take a slightly more manageable example - one might have an individual with Primary Name of Carolyn Janice Cherry. She could be given (as now) an Alternate Name of C. J. Cherryh and in future, this could be marked up as a (supplementary) pen-name. Imagine we have a BookPublished attribute, with value = the book's title. One might then have (turning it into a narrative sentence) something like "Carolyn Cherry published The Pride of Chanur in 1981." The (crucial) missing bit is the pen-name - and we can do that already using a witness with a Role of (say) "PenName". The witness would be set to a name-only witness, and the value of the witness would be "CJ Cherryh". The narrative sentence would then be something like "Carolyn Cherry published The Pride of Chanur in 1981, under the name CJ Cherryh."

There are a few possible shortfalls - e.g. there would be no cross checking between the "CJ Cherryh" in the witness role and the "C. J. Cherryh" in the Alternate Names - so I'd never pick up on my inconsistent punctuation.

This idea comes with the limitations that the pen-name, like any witness names, wouldn't appear in non-narrative reports (unless anyone knows better). But that's a bigger and more important, separate issue.

I am therefore questioning whether approaching Supplementary Names via the name-only witness and (disconnected) Alternate Names, might not be reasonably adequate? If one wanted the Supplementary name to appear in the Narrative as "real" names, then the answer is simply to turn it into a Timeline name.

Maybe....

[ColeValleyGirl]

Totally off-topic but C.J. Cherryh blurbed the original American edition of my book... Lovely woman.

[davidf]

Taking your helpful reply piece by piece (I will try and then pull it all together - I think we may actually have two closely related Wish List Items - so closely related I think I want to keep them together as two requirements in one Wish List Request):

Items in Blue are areas where I am aware that more "requirement detail" has to be worked out - without trespassing into "solution detail"?

I have changed "Supplementary Name" to "Context Name" as I think that is a clearer name.

I really have problems with any proposal that leads to CP providing such facts and those being the only ones that use Supplementary Names. The whole (delightful) point about user defined facts is that the user can supply their own, however mad it may appear to the rest of us.

Yes, I'm uncomfortable with that which is why I tried to think my way through avoiding this in the last half of my last post. It's still evolving; Next evolution:

Context Names

Requirement

To be able to associate specific names of an individual (such as a stage name or pen name) with specific facts or contexts.

Benefit

This handles the situation were someone may be known by a different name (e.g. Marilyn Monroe) in one context (e.g. films) to the name that we are using (e.g. Norma Jeane Mortenson) when documenting their genealogy

Notes

1. Make the Fact Description dialogue for all facts contain a check box in the list of fields for "Context Name"
2. Where this box is checked for a fact, "Context Names" are enabled which means the user is able when creating a specific fact to select which of the individual's names is to be associated with this fact. Technically I think it may be better to select the NAME.TYPE. - but the user is unlikely to notice the difference since it looks like a one-to-one relationship. Selection could be by :
   • Either an icon alongside the fact (RHS) operating a bit like the "Select and add media to fact" icon
   • Or an extra field appearing in the create fact dialogue a bit like the "cause" field appears in the create death fact dialog. This field could be either a "type ahead" type of field operating on the array of all names - like a Place field, or it could be a pull-down list populated by that array.
3. All the above options need an "Add Name" option (to avoid the irritation of having to back out because you did not create the name first) which will prompt for the name and the name type.
4. Ideally any Name Selection dialogue would show the available names with their name types.
5. NAME.TYPE contains the string to be used in sentences - which may not be ideal, but in the absence of additional fields is probably a pragmatic approach.
6. If the V7 Names & Titles Dialogue does not give access to NAME.TYPE, it needs to. (If it does not, do we extract this as a single GEDCOM compliant Wish List Item?)
7. A "sentence code" is required for the Context Name and the Name Type - possibly {contextname} & {nametype} - so that the user can build any required sentences in the Fact Description dialogue. (e.g. "{individual} {label} <'{value}'> <({date} {place}) <, using {contextname}> <as their {nametype}>."
8. There is no reason why any of the individual's names should not be used as a "Context Name"
9. I am keeping this separate from "Witnesses" which are associating other Individuals with a fact, whilst this is associating other names of the fact owner with the fact.

Discussion Threads
This thread
Data reference for witness (21122) particularly The 2nd paragraph of [url=viewtopic.php?p=129702#p129702Øivind's post[/url]

Associated Wish Lists
Enabling Dating of Names and the use of the Name Current at the time of an Event.Attribute start - which may interfere with the way NAME.TYPE is used in the above.

---------------------------------

Enabling use of Context Names through the Fact Definition dialogue, I think addresses many of your issues.

Others are much more problematic, I suggest. According to Wikipedia, Dean Koontz has 10 different pen-names . I imagine that some of them could be used in parallel, as well. That certainly happens with some authors. How would one specify which name to use - and how would that specification be robust in the face of changing Alternates?

You enter all the names as vontext names, with type "Pen Name", and then associate the appropriate name with each of the "Publication Facts"?

To take a slightly more manageable example - one might have an individual with Primary Name of Carolyn Janice Cherry. She could be given (as now) an Alternate Name of C. J. Cherryh and in future, this could be marked up as a (supplementarycontext) pen-name. Imagine we have a BookPublished attribute, with value = the book's title. One might then have (turning it into a narrative sentence) something like "Carolyn Cherry published The Pride of Chanur in 1981." The (crucial) missing bit is the pen-name - and we can do that already using a witness with a Role of (say) "PenName". The witness would be set to a name-only witness, and the value of the witness would be "CJ Cherryh". The narrative sentence would then be something like "Carolyn Cherry published The Pride of Chanur in 1981, under the name CJ Cherryh."

Or via a customised fact as specified above: "{individual=Carolyn Cherry} {label="published"} <'{value="The Pride of Chanur"}'> <({date="in 1981"} {place}) <, using {contextname="C.J.Cherryh"}> <as their {nametype="Pen Name"}>."

There are a few possible shortfalls - e.g. there would be no cross checking between the "CJ Cherryh" in the witness role and the "C. J. Cherryh" in the Alternate Names - so I'd never pick up on my inconsistent punctuation.

This idea comes with the limitations that the pen-name, like any witness names, wouldn't appear in non-narrative reports (unless anyone knows better). But that's a bigger and more important, separate issue.

I am therefore questioning whether approaching Supplementary Context Names via the name-only witness and (disconnected) Alternate Names, might not be reasonably adequate? If one wanted the Supplementary context name to appear in the Narrative as "real" names, then the answer is simply to turn it into a Timeline name.

I think the above shows a way to answer most of these by enabling Context Names to be actual names associated with a specific fact rather than force the Witness functionality to do something not intended.

I'm hesitating to say just turn it into a Timeline Name, I think there is a clarity between time associated names (Timeline Names) and context specific names (Context Names) that I don't want to interfere with. There is some detail to Timeline Names that I will try to think through in a separate post.

Using "Name Only" Witnesses gets you a long way - but has to be a known and documented work around. And as you say comes with various complications concerning consistency. By "properly structuring" this using GEDCOM features (particularly NAME.TYPE) we can avoid many of these problems. With Custom Facts, you could also do "Where Used" on a specific Name or Name type.

(If we had a simple Wish List Item to just enable GEDCOM NAME.TYPE (other than via the All tab), I'm sure we would then come up with an "obvious" enhancement to link NAME.TYPEs to facts!)

[davidf]

Mike (much) earlier said:

It would be feasible to identify a particular NAME instance by a structure such as NAME[type="IMMIGRANT"].

This is an attractive idea, but if the NAME.TYPE is not unique, we could for instance have numerous names of TYPE="Pen name". If we want to be able to say X used the name Y as a "Pen name", we need somewhere to store the string "pen name" or "stage name" etc.
My specification (above) currently anticipates

5. NAME.TYPE contains the string to be used in sentences - which may not be ideal, but in the absence of additional fields is probably a pragmatic approach.

Is there a way to resolve this? We want NAME.TYPE to do two things (which are not always compatible):

1. Hold a Type Identifier
2. Hold a string for use in sentences

[tatewise]

Perhaps you could take a leaf out of GEDCOM 7.0.1.
On Page 50 it defines among other things:

PERSONAL_NAME_STRUCTURE :=
n NAME <PersonalName>
+1 TYPE <Enum>
+2 PHRASE <Text>

A TYPE (p.82) is used to specify the particular variation that this name is. For example; it could indicate that this name is a name taken at immigration or that it could be an ‘also known as’ name. See the NAME.TYPE enumeration (p.89) for more.
Note — Alternative approaches to representing names are being considered for future versions of this specification.

Later on Page 74 it explains the use of the PHRASE tag:

PHRASE (Phrase)
Textual information that cannot be expressed in the superstructure due to the limitations of its datatype.
Example — A date interpreted from the phrase “The Feast of St John” might be
2 DATE 24 JUNE 1852
3 PHRASE During the feast of St John
Example — A name given to a foundling orphan might be
1 NAME Mary //
2 GIVN Mary
2 TYPE OTHER
3 PHRASE given by orphanage

So TYPE holds the Type Identifier and PHRASE holds the text for use in sentences.

[davidf]

Timeline Names

In addition to "Context Names" - associating a particular name variation with a specific fact (e.g. a stage name with appearance in a play), others have expressed a need to be able to report facts using the name by which the person was known at the time.

For instance, after marriage a woman may or may not use her husband's surname.

The need for "timeline names" intercepts with the need for "context names". In theory you could just associate a name with all facts from a certain point onwards but that is laborious and prone to error. Context Names also need to be distinct because you could have, for instance, a woman who normally uses her husband's surname (a timeline name), but uses her maiden name in a professional context (context name).

Below is the next draft of a wish list request for Timeline Names

Timeline Names

Requirement

1. Where individuals are known by different names at different times, there is a need to be able to record effectivity dates of the alternative names.
2. It should be a user choice as to whether facts are reported using the Primary Name (NAME[1] as at present) or using a "Current Name" - the name at the time the event being reported actually occurred (or immediately prior to it if the event was a name changing event).

Benefit
Sentences and reports could use the name by which the person was known at the time of the event (or immediately prior to it if the event was a name changing event). At the moment it looks strange, for instance, to report that the "death was notified by Sarah Smith", when in fact at the time she was married and was called and signed as "Sarah Jones".

General Notes

1. Implementation might be possible by %INDI.NAME[1]._DATE% in a similar manner to %INDI.TITL[1].DATE%
2. To enable checking of the variety of names that have been setup a dialogue similar to, or an enhancement of, the Names and Titles dialogue is required that shows all names, and their effectivity dates. Implementation of NAME.TYPE may assist because that can hold details such as "adoptive name", "married name" etc.
3. Use of Timeline Names should be an option. If not set FH works as at present.
4. If selected all sentences and phrases using a "name" would select the relevant "timeline name".
5. If selected the functionality to determine the current timeline name would also be used in processing Witness phrases and sentences.

Setting the Option

There has to be an option somewhere as to whether reports (and other forms of output - which?) are to refer to the "Primary Name" (NAME[1]) or to refer what we might call the "Current Name" (the time-line name going into the event or attribute). Possible scenarios:

1. The user always wants to use the "Current Name" for all individuals for all facts in the project
   • This could be handled by a Project Variable - set in Preferences,
2. The user may want to use the "Current Name" for specific individuals for all facts.
   • This probably requires an Individual Variable - set in their property box?
3. The user may want to run a report using "Current Name" for all facts, irrespective of other settings (e.g. an audit report on names)
   • There could be a checkbox on the report setup dialog

Determining the Current Timeline Name

1. In designing the implementation care will need to be taken to detect whether it is the name immediately prior to the event that should be used, or the name consequent on the event. (For instance you would use the bride's maiden name (name immediately prior) in a marriage report not the married name she acquired as a consequence. The following "rules" might achieve this:
   1. If time line dates overlap on the fact date (possibly due to user error), the date used is the one with the latest start date, except,
   2. If a name's effectivity ends on the fact date (and another potentially starts on that date - as might be legitimately expected for instance on marriage), the name ending (e.g. the expiring maiden name) is used.
   3. If there is no name effective on a particular date, the Primary Name should be used (as at present)
2. Rules such as the above probably make it unnecessary to ensure that timeline events do not overlap and that they form a continuous chain. If users get unexpected results they can examine the names they have setup.

Interaction with Context Names

An allied Wish List introduces the idea of Context Names, where a specific name may be associated with a specific fact - for instance a stage name may be associated with an "Appeared in" fact. (See Wish List item referring to "Context Names".)

In designing the implementation of both Context Names and Timeline Names care will have to be taken to ensure that if, for instance, a woman had a birth name, name by adoption, a married name (official sequence of names) and a stage or pen name, that the later is not used in normal reporting.

It is reasonable that any name could be selected as a Context Name (for instance, a maiden name may be used after marriage in a professional context), but we may not want all Context Names to be treated as Timeline Names. A means is therefore needed to distinguish them.

Options for distinguishing Timeline Names from Context Names

1. If Context Names are undated, they cannot be used as Timeline Names - unless set as the Primary Name and ("use Current name" is off or there is no effective Timeline Name).
   • It may be desired to "date" Context Names - where for instance a person used multiple stage names. Even though the appropriate one would be selected by the user via the Fact dialog, it could still be useful to see the effectivity dates of any name. Putting the applicable dates into the NAME.TYPE means they would appear in sentences where you want to refer to name type.
2. Timeline Names could be flagged by use of a prefix in the NAME.TYPE such as "TLN:"
   • If such a name was used as a Context Name, steps would be needed to ensure that the prefix did not appear in any sentences referring to the NAME.TYPE
3. A custom NAME.TYPE.TYPE is developed to indicate the Type of Type (Timeline Name type, or Context Name Type).
   • A better option is available - see below
4. (As suggested by Mike above) The NAME.TYPE.PHRASE construction in GEDCOM 7.0.1 is used.
   • NAME.TYPE is then a "database descriptor" of the Name and could have the Prefix "TLN: " or even the full string "Timeline Name; " (in the Project Language?)
   • NAME.TYPE.PHRASE is then the "text to be used in sentences".

Implementation of NAME.TYPE.PHRASE would allow Timeline Names to be distinguished from Context Names and would keep the sentence text separate from the type descriptor. The latter (Mike's suggestion) is my preferred option.

Discussion Threads
Names and Name Changes over time (21126)
arising from
Data reference for witness (21122)
Note also AS requirement
Witness name on a marriage (21297)

How much of the above goes into a Wish List Item - and how much do we leave to CP to decide on when implementing the item? I think quite a bit because it explains the functionality that we are wishing for.

[tatewise]

Setting the Option
There has to be an option somewhere as to whether reports (and other forms of output - which?) are to refer to the "Primary Name" (NAME[1]) or to refer what we might call the "Current Name" (the time-line name going into the event or attribute).

I can imagine users wanting all forms of output: Reports, Diagrams, Queries, and even the Property Box Facts tab.

I wonder if there is any mileage in Name Qualifiers?
e.g.
INDI.NAME:PRIMARY displays the Primary Name INDI.NAME[1] regardless of any potential Time Line or Context names.
INDI.NAME.TIME_LINE displays the associated Time Line name if one exists otherwise the Primary Name.
INDI.NAME.CONTEXT

Determining the Current Timeline Name

1. In designing the implementation care will need to be taken to detect whether it is the name immediately prior to the event that should be used, or the name consequent on the event. (For instance you would use the bride's maiden name (name immediately prior) in a marriage report not the married name she acquired as a consequence. The following "rules" might achieve this:
   1. If time line dates overlap on the fact date (possibly due to user error), the date used is the one with the latest start date, except,
   2. If a name's effectivity ends on the fact date (and another potentially starts on that date - as might be legitimately expected for instance on marriage), the name ending (e.g. the expiring maiden name) is used.

Why not choose the one with the earliest start date, then the exception is not an exception?
(Maybe there was an earlier explanation that I missed. )

[davidf]

I wonder if there is any mileage in Name Qualifiers?
e.g.
INDI.NAME:PRIMARY displays the Primary Name INDI.NAME[1] regardless of any potential Time Line or Context names.
INDI.NAME:TIME_LINE displays the associated Time Line name if one exists otherwise the Primary Name.
INDI.NAME:CONTEXT

(my amendments in red)

I started to wonder about this at one stage, but (unless someone can explain otherwise)

• Can you use two qualifiers "stacked"? Name Qualifiers currently seem to be about formatting the chosen name ("SQL columns"), not choosing the name ("SQL rows"); is it wise to mix two functionalities where the NAME.TYPE is available?
• In sentence templates {name} would be interpreted according to the selected option. (I suppose we could have {currentname} which either has to be an over-ride irrespective of options set, or only used if the "use current" option applies)?.
• Are qualifiers the best way to set up say queries where you may want to work with different name types - or does NAME.TYPE with filters do the trick?

How might we construct a query to show for each person with multiple names all their stage or screen names? I don't think a Fact Query does the job because "deconstructing the FactOwner" does not work because Facts are associated with Individuals not Name variations. We could take all facts and exclude those that do not have an associated Context Name, and then display those facts with the Context name and Context NAME.TYPE - but that would have duplicates so it's not necessarily the result we might want.

Do extra data references help beyond NAME.TYPE and NAME._DATE and NAME.PHRASE?

Can we construct an Individual query that for a field (i.e. name in this case) can index through all variants - one line per variant? I'm not sure we can. A diagram would display with just the indexed NAME to give:

Code: Select all

Name,                  Name Type
Norma Jeane Mortenson, Timeline: Birth Name (Surname: Mother's Husband)
Norma Jeane Baker,     Birth Name (Surname: Mother's 2nd Husband)
Norma Jeane Dougherty, Timeline: Married Name
Norma Jeane DiMaggio,  Timeline: Married Name
Norma Jeane Miller,    Timeline: Married Name
Marilyn Monroe,        Context: Screen Name (Surname: Mother's Maiden Name)

I think that is a restriction on FH querying rather than the data structures anticipated for this wish list.

A construction NAME.TYPE["Birth Name"] would struggle if I used the NAME.TYPE as in the above example, due to there being more than one of a particular type, me combining the NAME.TYPE.TYPE into the contents of NAME.TYPE and then including explanation that more properly lives in NAME.NOTE2.

[davidf]

Why not choose the one with the earliest start date, then the exception is not an exception?
(Maybe there was an earlier explanation that I missed. )

I think I felt that if Names had been entered "inexpertly", it was probably the one with the most recent start date when compared with the fact date that would be best.

[tatewise]

The usual case is where a name changes on a particular date similar to the maiden to the married name change.
Setting the rule to accommodate inexpert use, leads to confusing Help documentation and user understanding.
IMO set the simple rule for the usual case and let inexpert use take its course.

Name qualifiers were perhaps not such a good idea.
Maybe I was thinking more along the lines of special indexes akin to [first] and [last].
i.e. INDI.NAME[primary] and INDI.NAME[time_line]

[davidf]

Maybe I was thinking more along the lines of special indexes akin to [first] and [last].
i.e. INDI.NAME[primary] and INDI.NAME[time_line]

Well INDI.NAME[primary] would always be INDI.NAME[1], and INDI.NAME by itself in a multi-name record would default to returning INDI.NAME[1]?

I'm not sure how easy it would be to handle "alternate index values" for a name,

• the traditional one based on physical position in the record (where [first] and [last] would already have a meaning per help?) and
• a timeline index based on the dates associated with names - for those flagged as timeline names and having dates

- presumably internally FH would have two name index arrays and just index into the appropriate one depending on the setting of "use current" in the individual's record.

If CP did this (and I think we are well into telling CP how to do their job here!), we would have to ensure that the Primary Name was always NAME[1] in the timeline index if it was undated - or in the sequence if dated. Yet the Primary Name's position in the physical record would have to determine the Name at the top of for instance a diagram box (or report section) - that is one of the purposes of the Primary Name.

I'm not at all sure that double name indices is a good idea! But NAME[lastdate] might be useful - if someone made the case.

[davidf]

The usual case is where a name changes on a particular date similar to the maiden to the married name change.
Setting the rule to accommodate inexpert use, leads to confusing Help documentation and user understanding.
IMO set the simple rule for the usual case and let inexpert use take its course.

But what is the usual use? You could make the case for always entering timeline dates as "frm dd/mm/yyyy" - without a "to" date. In some respects that is logical if your are following through someone's life because when a different name is adopted you don't know the "end effectivity date".

If you only entered "from dates", the logic is the name at the time of an event (or an attribute start) is the name with the most recent start date prior to the event/attribute-start. You could say that setting an "end date" for a timeline date would be the exception (reverting to primary name).

Thus a woman (who had been adopted) may have married (using her adoptive name) on 1st May 1920 and her married name was entered as "frm 1 May 1920". Then when she (as a married woman) registers the birth of her first child a year later, the most recently started timeline date would be her married name. Taking the earliest name would mean using her birth name not even her adoptive name.