* Surname prefix (SPFX) -- more generally, handling structured names.

Questions regarding use of any Version of Family Historian. Please ensure you have set your Version of Family Historian in your Profile. If your question fits in one of these subject-specific sub-forums, please ask it there.
User avatar
fhtess65
Megastar
Posts: 637
Joined: 15 Feb 2018 21:34
Family Historian: V7
Location: British Columbia, Canada
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by fhtess65 »

This isn't something I see in my own family - it's generally just first and last name, sometimes a middle name - often with declensions, but not the gens/Clan name you cited. There are diminutives used within the family, but not on records.

Of course, the furthest of gotten back with any degree of certainty is the early 1800s...after that, it becomes very murky.

Teresa

davidf wrote: 20 Jun 2022 17:41
fhtess65 wrote: 20 Jun 2022 17:06 ... I'm a user of FH and recently have made it my key software of choice for my tree. I have many Polish names in my tree and as my research goes further back, hopefully, at some point, I may find some Prussian names that will include a von or other prefix.
Teresa

From trashing around trying to get to grips with some of the international issues (i.e reading Wikipedia and other internet sources) I see reference in discussion of Polish Names to
WIkipedia wrote:praenomen (or given name), nomen gentile (or gens/Clan name) and cognomen (surname)
Do you recognise this distinction and does it have applicability in genealogical research? If so how would you "slash write" such a name in the NAME field? And how well does that meet your present and future requirements? Are there other structures that may appear unusual to English-centric users?
---
Teresa Basińska Eckford
Librarian & family historian
http://writingmypast.wordpress.com
Researching: Spong, Ferdinando, Taylor, Lawley, Sinkins, Montgomery; Basiński, Hilferding, Ratowski, Paszkiewicz
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

tatewise wrote: 20 Jun 2022 17:54 don't get hung up on the suffix being III as it may just as easily be Jnr, Snr or PhD. It is anything suffixed to the surname.
Well, in Wilbur /van Splink/ II the II is suffixed to the surname, but is included in the name, so per FH, because it is outside the slashes, it is a "Given Name".

II, Jnr, or Snr may be part of the name - which identifies the person (in this case distinguishes the father from the son) - so they do lie in the NAME field - but currently there is no SSFX (Surname Suffix). PhD however is not part of the name - it is a "post-nominal" and should therefore go in the Name Suffix NSFX.
tatewise wrote: 20 Jun 2022 17:54 The point is that the GIVEN_ALL qualifier returns all except the /surname/ part from NAME regardless of whether it is a given name or not.
FH says: "All given names - ie. everything except the surname."
Is there a potential user requirement for NAME:SURNAMEPREFIX which is within the scope of CP? It would require them to go through developing the logic as you have done for parsing the NAME field. That would effectively give us a custom function so we can set SPFX = NAME:SURNAMEPREFIX. (Getting a bit close to defining a solution rather than a requirement - but "Custom functions" is an interesting idea!)
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by AdrianBruce »

tatewise wrote: 20 Jun 2022 16:16 Adrian, you must have overlooked the following:
2 GIVN for the Given names
2 SURN for the Surname
...
I didn't overlook them - it seemed to me that they aren't mandated by the Specification and FH allows the creation of just some parts while allowing others (like GIVN and SURN) to be omitted. So, being investigative, I left them out.
tatewise wrote: 20 Jun 2022 16:16 ... The GEDCOM specification says that the level 2 parts should only be used if the 1 NAME format cannot be used.
I read it as a bit more woolly than that, but yes. Sort of. But again, it was simply an investigation to see what might happen if the extra bits did come into play.
Adrian
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by AdrianBruce »

fhtess65 wrote: 20 Jun 2022 17:06 But would it really be for one? I'm a user of FH and recently have made it my key software of choice for my tree. I have many Polish names in my tree and as my research goes further back, hopefully, at some point, I may find some Prussian names that will include a von or other prefix. ...
I certainly think that the American market has space for software with an (American) English User Interface but the ability to deal with names from other cultures. I think, for instance, of Spanish compound family names, which change from generation to generation. It may be that once you have switched off copying down the father's family name to the children as a default, then nothing else is particularly urgent - but I don't know.
Adrian
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

AdrianBruce wrote: 20 Jun 2022 20:22 It may be that once you have switched off copying down the father's family name to the children as a default, then nothing else is particularly urgent
Possibly, but that could be because we have been spoilt by the "English surname" tradition and for many of us relatively easy research from 1837 (beginning of English Registration) onwards - that may also constrain the thinking of software developers.

As an aside I have been trying to identify the birth details of a mother seen in the (English) 1871 Census as "b~1821 Scotland", I know the Main Given and Maiden Surname (Mary Graham) for the woman concerned, but that does not narrow the field very much - the name is not exactly unusual! This was the husband, David Johnston(e)'s second wife, and from the names of the children of the two marriages there is some evidence that the Presbyterian naming convention was being followed (with its quirks).

It would be nice if my genealogical software was able to project forwards the expected names of children (and missing children) and to project back the expected names of grandparents etc. That is not a functionality often seen in software; if at all - but if we were in a culture which works with patronymics - such functionality (projecting possible names backwards and forwards through the generations) might not seem so far fetched.

To me it's "not urgent" usually just a minor inconvenience - but it would be so useful with this "particular puzzle".

In many ways our imagination is restricted by our collective experience. But our collective experience is restricted by the demographics of those attracted to use our software.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by tatewise »

Adrian, I don't understand why you say the GIVN and SURN tags are not mandated by the GEDCOM specification.
They are mandated to exactly the same degree as the ones you mentioned. See Page 37 of GEDCOM 5.5.1 specification with examples on Pages 55 & 56.
PERSONAL_NAME_PIECES:=
n NPFX <NAME_PIECE_PREFIX> {0:1} p.55
n GIVN <NAME_PIECE_GIVEN> {0:1} p.55
n NICK <NAME_PIECE_NICKNAME> {0:1} p.55
n SPFX <NAME_PIECE_SURNAME_PREFIX {0:1} p.56
n SURN <NAME_PIECE_SURNAME> {0:1} p.55
n NSFX <NAME_PIECE_SUFFIX> {0:1} p.55
FH does support all of them via the All tab and they can be customised into the Main tab or a custom tab.
That is what I offered to Kaaskop back on Thu 16th Jun 2022 14:20 and he extended as explained on Sun 19th Jun 2022 13:00 so he seems very pleased.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by Kaaskop »

Indeed I'm very pleased!

I'm trying to fully understand this conversation and have the feeling that there is confusing between facts, wishes, the Gedcom standard and software.
In my opinion The Gedcom standard is there, maybe not ideal and you don't have to like it. In the standard it's allowed to use name pieces. Use NAME_PIECE_SURNAME for index purposes and NAME_PIECE_SURNAME_PREFIX for the first part of the surname you don't want to use for indexing the NAME. If you start working from the name pieces the software can construct in many ways names and pass them along the way you want. This works in every language or culture and do you want to sort on more then one surname use alternative names.

With the plugin I can fill the different name pieces and let FH construct the Name as needed. Till now, I have seen that (most?) querys, windows etc. can be modified by adding an extra column (surname in my case) for sorting purposes. It would be nice if the standard behavior of FH (at least in the underlying structure) would be based on name pieces instead of on name personal. Now I have to customize quite a lot to work with FH.
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by AdrianBruce »

tatewise wrote: 20 Jun 2022 21:38 Adrian, I don't understand why you say the GIVN and SURN tags are not mandated by the GEDCOM specification. ...
I suspect I may not be getting over what I mean by "mandate". To revert to my example of
1 NAME James Tiberius /de Kirke/
2 NPFX Captain
2 SPFX de
2 NSFX III

This appears, by my reading of the GEDCOM 5.5.1 standard, to be perfectly legal GEDCOM. FH produced those lines so FH thinks it's legal GEDCOM - though I'd hardly blame Calico Pie if they got such an unusual item as SPFX wrong. However, it struck me that the only data on the 1 NAME line that was expanded / analysed / whatever below, was the "de". Instinctively (and instinct is not logic) this felt odd and I would have thought that this was a more natural encoding:
1 NAME James Tiberius /de Kirke/
2 NPFX Captain
2 GIVN James Tiberius
2 SPFX de
2 SURN Kirke
2 NSFX III

In this rendering everything on the 1 NAME line is analysed on a 2 line below. My instinct would have been to mandate that if you do any analysis of the 1 NAME line below, then you should expand / analyse all of it. Thus in my example, I'd used the SPFX line, so I ought to also use the GIVN and SURN. However, the GEDCOM standard doesn't mandate this full expansion / analysis, it just permits me to expand / analyse only the SPFX. That's what I was trying to get over. The mandate that I was instinctively looking for, and GEDCOM isn't supplying, is a mandate about the combination of the fields. And I have no idea how to encode such a mandate in the GEDCOM definition format, by the way!

So far as I can see, your plug-in produces the full combination of GIVN, SPFX and SURN (in this case) - exactly what my instinct was expecting to see, so we do appear to be in agreement of what ought to appear!
Adrian
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by AdrianBruce »

Kaaskop wrote: 21 Jun 2022 09:01... I'm trying to fully understand this conversation and have the feeling that there is confusing between facts, wishes, the Gedcom standard and software. ...
I suspect that, like many exchanges in this User Group, we're not confused about the difference between facts, wishes, etc., but we can be guilty of not making it totally clear whether we're talking about things that could be done with FH as it stands out of the box, or with FH via a plug-in, or with coding changes to FH or with changes to the GEDCOM standard or ...

I confess that I also like the intellectual challenge of thinking stuff through and also learning that, for instance, while I might be happy to sort van Gogh in with all the other vans, others seriously need to sort him in with Gogh...
Adrian
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by tatewise »

Adrian, I still do not understand what you mean by "mandate".
Neither FH nor GEDCOM mandates that any of the level 2 fields must mirror the contents of the NAME field or vice versa.
They may all contain anything or nothing, and are valid GEDCOM syntactically, even if the semantics are dubious.
FH never automatically fills in any of the level 2 fields from the NAME field or vice versa.
The NAME, NPFX, SPFX & NSFX values that you quote must have all been entered manually by you (or perhaps a plugin or perhaps imported from another product).
I say again, FH did not mandate/create any of those values by itself.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

Are we in danger of getting confused because of the ambiguity behind the meaning of "mandate"?

I had a bank mandate that allowed me to operate the back account of my late mother - I was mandated to operate it if I chose to do so (In practice I preferred that she did so - until the power of attorney kicked in)

In the UK the maximum speed on a UK Motorway for cars is a "Mandatory limit" of 70mph - which you must abide by.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by AdrianBruce »

tatewise wrote: 21 Jun 2022 10:12 Adrian, I still do not understand what you mean by "mandate".
Neither FH nor GEDCOM mandates that any of the level 2 fields must mirror the contents of the NAME field or vice versa. ...
Yes. That's what I've been trying to say - that GEDCOM doesn't mandate the existence of those level 2 fields. And you appear to be agreeing with me. I've also been trying to get over that I find this lack of mandate mildly surprising, illogical even, in some combinations of circumstances.

I must admit that I missed that the content of the level 2 fields might actually contradict the NAME field. But it can - I just tried it in the All tab by setting the SURN field to be different from the NAME field. Strange... But it is what it is.
tatewise wrote: 21 Jun 2022 10:12 ... The NAME, NPFX, SPFX & NSFX values that you quote must have all been entered manually by you ...
Yes, the level 2 items were entered by me on the ALL tab, as an investigation. I thought I'd said that.
tatewise wrote: 21 Jun 2022 10:12 ... I say again, FH did not mandate/create any of those values by itself.
Yes, I totally agree.
Adrian
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

AdrianBruce wrote: 21 Jun 2022 09:50 ... I might be happy to sort van Gogh in with all the other vans, others seriously need to sort him in with Gogh...
With only a few that may be the personal case, but when the numbers start increasing and the unprefixed surname is often used ...

Consider from a different field (Music):
Wikipedia, https://en.wikipedia.org/wiki/Carl_Maria_von_Weber wrote:Carl Maria Friedrich Ernst von Weber (18 or 19 November 1786 – 5 June 1826)[1][2] was a German composer, conductor, ....
Weber was born in Eutin, Bishopric of Lübeck, as the eldest of the three children of Franz Anton von Weber [de] and his second wife, Genovefa Weber, a Viennese singer.

or
Wikipedia, https://en.wikipedia.org/wiki/[b wrote:Herbert_von_Karajan[/b](]Herbert von Karajan (German: [ˈhɛʁbɛʁt fɔn ˈka(ː)ʁajan] (listen); born Heribert Ritter[a] von Karajan; 5 April 1908 – 16 July 1989) was an Austrian conductor. ...
The Karajans were of Macedonian Greek[3][4][5][6][7][8] ancestry. Herbert's great-great-grandfather, Georg Karajan (Geórgios Karajánnis, Greek: Γεώργιος Καραγιάννης), was born in Kozani, in the Ottoman province of Rumelia (now in Greece), leaving for Vienna in 1767, and eventually Chemnitz, Electorate of Saxony.[9] Aromanian heritage for the Karajans has also been claimed.[10]
His last name, like several other Ottoman-era ones, contains the Turkish language prefix "kara", which means "black".
(Admittedly, WIkipedia on Vincent van Gogh does refer to him and is family as van Gogh and the van Goghs and explicitly says "In this Dutch name, the surname is van Gogh, not Gogh". Perhaps there are shades of usage between Dutch and German/Austrian?

As for that built in Turkish prefix!
Last edited by davidf on 21 Jun 2022 11:47, edited 1 time in total.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by Kaaskop »

What is in a name...
van Wijk, van Gogh, van der Meer are all surnames but surnames including the prefix. Search, sort, index is done only at Wijk, Gogh or Meer.
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by Kaaskop »

I introduce myself as Mr. van Wijk. But if someone is reading an alfabeticaly list of names I will be almost et the end.
User avatar
AdrianBruce
Megastar
Posts: 2090
Joined: 09 Aug 2003 21:02
Family Historian: V7
Location: South Cheshire
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by AdrianBruce »

Kaaskop wrote: 21 Jun 2022 11:26 ... van Wijk, van Gogh, van der Meer are all surnames but surnames including the prefix. Search, sort, index is done only at Wijk, Gogh or Meer.
A useful summary, thank you!
Adrian
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

Kaaskop wrote: 21 Jun 2022 09:01 ...
With the plugin I can fill the different name pieces and let FH construct the Name as needed. Till now, I have seen that (most?) querys, windows etc. can be modified by adding an extra column (surname in my case) for sorting purposes. It would be nice if the standard behavior of FH (at least in the underlying structure) would be based on name pieces instead of on name personal. Now I have to customize quite a lot to work with FH.
I think this is a key issue. FH is built to use the NAME field as the primary identifier of INDI (ID aside) and many standard diagram schemes, queries and reports etc are built to use NAME. There is little value in customising them to use GIVN+" "+SPFX+" "+"SURN" when the displayed or printed result looks the same. You end up with two systems to develop and maintain. Or am I in my Anglo-centric world missing a key distinction?

Given where FH is (as it seems many programs are), NAME is key (even if only small "k"). By making the use of NAME mandatory (i.e. must always be completed/filled in) you ensure that you don't get for instance:
&quot;Unnamed&quot; Individual with a GIVN and SURN
"Unnamed" Individual with a GIVN and SURN
Screenshot from 2022-06-21 12-02-17.png (18.99 KiB) Viewed 1931 times
With NAME always filled in you can also find that diagrams and reports work as intended. The use of the name pieces, particularly SURN is primarily to provide a sorting or filtering key. Doing anything else is going against the grain of how FH works - which is "unwise/brave" and unlikely to be implemented before FH v20! Or again am I in my Anglo-centric world missing a key distinction?

(Possibly: I have raised in a response to Adrian that sometimes you may refer to people and families with or without the prefix ("the Van Goghs" but "the Karajans" and "the Webers", indexed(?) under "van Gogh, Vincent", "Karajan, Herbert von", "Weber, Carl Maria von" but(!) "du Pré, Jacqueline") and controlling this gets into sentence structures and the need for a USED_SURNAME attribute!)

My gut feel is that the way to go on this (eventually) is to have an option to "switch on" "Advanced Name Processing" the primary effect of which is to run a routine whenever any of the NAME, GIVN, SPFX, or SURN fields are added/deleted or amended to align them such that NAME=GIVN+" "+SPFX+" "+"SURN" - possibly with a dialog to allow manual editing such as:

name alignment dialog
name alignment dialog
Screenshot from 2022-06-21 12-08-01.png (13 KiB) Viewed 1931 times

(The memo field is a result of me pondering personalised "alignments". As seen in previous posts I am pondering how to hold "custom alignments" such that a maintenance routine - such as in Mike's plug-in does not over-write a carefully manually enter distinction. For instance the plug-in may not recognise "d'Artagnan" as SPFX and SURN due to the lack of a space between d' and Artagnan - you may want to hold "d'<space>Artagnan" in a Key: value pair Parseable:d'<space>Artagnan; and if it is found the alignment routine "respects" it in preference to anything else.)

Once you have your NAME GIVN SPFX or SURN fields complete and consistent can FH adequately handle the requirements of those who use surname prefixes?

Does this extend somehow to other Name Structures?
Mike has for instance pointed out that:
Wilbur John /Smith/ III is a valid name and I can make the argument that the III is a "given name" rather than a suffix attached to the end of the name like post-nominals, but at the moment NAME=GIVN+" "+SPFX+" "+"SURN" does not allow for this "structure"
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
avatar
Kaaskop
Platinum
Posts: 30
Joined: 16 Jun 2022 08:24
Family Historian: V7

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by Kaaskop »

If you use GIVN, SPFX and SURN every software program can easily construct the NAME (except FH) by doing that you can have the advantage of both: more flexibility with entering data and you follow the Gedcom standard. So Name stays mandatory but is build from the separate fields.
No blanc fields, search, sort, order etc. is possible on every name part you want.
"Doing anything else is going against the grain of how FH works" I thougt FH is following the Gedcom standard?
I don't agree with you working with separate fields makes it easier for a correct(?) input, easier sorting and searching and you get exact the same reports, why not?
Working with separate field doesn't change the structure it only specifies the different parts of a NAME in a more reliable way.
avatar
KFN
Superstar
Posts: 274
Joined: 20 Jun 2021 01:00
Family Historian: V7

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by KFN »

tatewise wrote: 20 Jun 2022 21:38 Adrian, I don't understand why you say the GIVN and SURN tags are not mandated by the GEDCOM specification.
They are mandated to exactly the same degree as the ones you mentioned. See Page 37 of GEDCOM 5.5.1 specification with examples on Pages 55 & 56.
PERSONAL_NAME_PIECES:=
n NPFX <NAME_PIECE_PREFIX> {0:1} p.55
n GIVN <NAME_PIECE_GIVEN> {0:1} p.55
n NICK <NAME_PIECE_NICKNAME> {0:1} p.55
n SPFX <NAME_PIECE_SURNAME_PREFIX {0:1} p.56
n SURN <NAME_PIECE_SURNAME> {0:1} p.55
n NSFX <NAME_PIECE_SUFFIX> {0:1} p.55
FH does support all of them via the All tab and they can be customised into the Main tab or a custom tab.
That is what I offered to Kaaskop back on Thu 16th Jun 2022 14:20 and he extended as explained on Sun 19th Jun 2022 13:00 so he seems very pleased.
By mandate, I take that to mean that each subtag to the NAME tag (for example, SURN tag) has a “min/max value” of 0:1 which means to me that it is not required (the zero), and has a maximum number of entries of one (the 1). So therefore a the NAME tag is required {1:1} but the subordinate tags (name_pieces) are not required.
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

Reinoud

I think we may be getting at cross purposes. When you said
Kaaskop wrote: 21 Jun 2022 09:01 I thought FH is following the Gedcom standard?
They do take pride in being one of the software products that does not have its own database and attempts to (pragmatically) follow the GEDCOM standard.

With statements like that (particularly I suspect in the Anglo-Saxon world) there is "following" and "following" (like the UK "complying with the EU Withdrawal Agreement" whilst admitting its proposals "breaks international law in a very specific and limited way"?! [ref: DW])

There are also choices "allowed" within the standard and there are "tolerated non-conformances".

I suspect the "minimal support" (i.e. via the "All tab") is a pragmatic attempt to follow the standard making use of "choices", "tolerated non-conformances" and "ambiguities". A number of us are questioning whether going forward that is adequate.
Kaaskop wrote: 21 Jun 2022 09:01 It would be nice if the standard behavior of FH (at least in the underlying structure) would be based on name pieces instead of on name personal.
I read the above as you saying "by default FH should use the name pieces rather the NAME" - which I suspect requires a major change to ensure that (for instance) everywhere:
  • where FH has previously called NAME it has to call the three Piece Fields
  • where it has called the qualified names (NAME:GIVEN, NAME:GIVEN_ALL and NAME:SURNAME etc.) it has to use the relevant Piece Field,
  • when it has called a subroutine to sort on NAME:SURNAME_FIRST, it has to use SURN+GIVN (or some would say SPFX+SURN+GIVN - which is to be built into the underlying structure?)
  • etc. etc.
That I would see as going against the grain which is to by default work with just the single NAME field and use NAME:GIVEN, NAME:GIVEN_ALL and NAME:SURNAME when it needs a "piece".

The alternative is to meet the problem at "Name" input/edit/delete allowing the option to enter Piece Parts and then to possibly automatically (rather than by plug-in) build a NAME field that can be used in the way that FH already does - which may look (to the user) as if it is using the Name Piece Parts by default. But I suspect any automatic build of the NAME is going to create sufficient problems to be a significant irritation and therefore there needs to be an option to manually build the NAME field.

If we want to see an enhancement (either in V7.1 or V8.0) we have to accept the way that CP has built the program and frame our wish list requests to at least work in sympathy with the "way it is". The above paragraph is how I think we may best do this. Others may have better ideas which is why we iteratively discuss possible wish list requests.
Kaaskop wrote: 21 Jun 2022 12:30 If you use GIVN, SPFX and SURN every software program can easily construct the NAME (except FH) by doing that you can have the advantage of both: more flexibility with entering data and you follow the Gedcom standard. So Name stays mandatory but is build from the separate fields.
This is why I think we may be at cross purposes and in danger of having a vigorous agreement!

I do not know other programs and how they can be confident that they can build NAME from the pieces as I suspect that NAME does not always equal GIVN+" "+SPFX+" "+SURN.

For instance if you have:
GIVN: Sebastien
SPFX: de l'
SURN: Aubespine
You have to program for the situation where you want to create Sebastien de l'Aubespine without a space between SPFX and SURN. Are we confident that every software program can easily construct the NAME (except FH) in a reliable way?

With FH giving primacy to NAME the user can enter Sebastien /de l'Aubespine/ and be confident that what was put in is what comes out in diagrams and reports etc.

Those of us contributing to this topic are pretty much agreed that whilst giving primacy to NAME handles "presentation" pretty well, we are agreed that there are circumstances where this give significant problems in sorting and filtering particularly when there are surname prefixes.

If we are saying, "OK let's raise our eyes from the simple "given_names surname" structure that we are used to" (two simple elements), at the same time as considering a single instance of where this structure is unsatisfactory (where there are surname prefixes - three elements), we ought to consider, "are there other name structures that might be problematic - or which could offer market opportunities - that could be considered at the same time?".
Last edited by davidf on 21 Jun 2022 15:43, edited 2 times in total.
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

davidf wrote: 21 Jun 2022 14:55 With FH giving primacy to NAME the user can enter Sebastien /de l'Aubespine/ and be confident that what was put in is what comes out in diagrams and reports etc.
I am aware that there may be an area that is unsatisfactory. In diagrams (and other output?) NAME:FULL appears to present the given names as input case, but the surname (as delimited by slashes) is in UPPERCASE. (You get Vincent VAN GOGH.) Likewise with NAME:SURNAME. You cannot change this in Text Schemes with NAME and Qualifiers, but you can avoid the issue with Name Pieces which I think all present as input.

However I think this is a problem not with giving primacy to NAME but with qualifiers presuming to know what case the user wants! =ToUpper() is available! Might there be a reason to request that Qualifiers do not mess with the case "as input"? (We might also ask for a =ToProper() function)
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by tatewise »

David, although not necessarily providing all the answers, are you are of...

Tools > Preferences > General tab Display surnames in upper case that can be cleared if you want mixed case as entered into the Name field displayed throughout FH including Diagrams and Reports.

%INDI.NAME:STORED% displays the Name field as entered in mixed case including the /surname/ slashes.
A variant of that STORED qualifier could presumably be implemented by CP that excluded the /surname/ slashes.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
avatar
Jean001
Famous
Posts: 129
Joined: 03 Mar 2021 11:49
Family Historian: V7

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by Jean001 »

As a former indexer, I have been following this discussion with interest. I have a thick ring binder full of notes on indexing the names of people. We followed guidance in British Standards, Anglo-American Cataloguing Rules, Chicago Manual of Style, Society of Indexers, etc.

Incidentally, there are two systems of ordering an index: letter-by-letter and word-by-word.

So, yes, the FH user needs to be able to enter the name so that indexing is correctly applied to his/her desire.

Perhaps a 'Sort as' option might be useful. In my project, there are a number of names that are 'wrongly' sorted in the Records Window (e.g. Mc/Mac and O'...). I'd like to re-order those names. (In an index, Mc... is sorted as 'Mac' and the apostrophe in O'... names is ignored.)
Jean
User avatar
davidf
Megastar
Posts: 951
Joined: 17 Jan 2009 19:14
Family Historian: V6.2
Location: UK

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by davidf »

tatewise wrote: 21 Jun 2022 16:08 David, although not necessarily providing all the answers, are you are of...

Tools > Preferences > General tab Display surnames in upper case that can be cleared if you want mixed case as entered into the Name field displayed throughout FH including Diagrams and Reports.
Ah, that solves that wrinkle! That little check box had not registered!
tatewise wrote: 21 Jun 2022 16:08 %INDI.NAME:STORED% displays the Name field as entered in mixed case including the /surname/ slashes.
A variant of that STORED qualifier could presumably be implemented by CP that excluded the /surname/ slashes.
How would %INDI.NAME:STORED% but without the slashes actually differ from %INDI.NAME% ?
David
Running FH 6.2.7. Under Wine on Linux (Ubuntu 22.04 LTS + LXDE 11)
User avatar
tatewise
Megastar
Posts: 28341
Joined: 25 May 2010 11:00
Family Historian: V7
Location: Torbay, Devon, UK
Contact:

Re: Surname prefix (SPFX) -- more generally, handling structured names.

Post by tatewise »

%INDI.NAME% honours the Display surnames in upper case setting so may display uppercase surnames.
%INDI.NAME:STORED% does not honour that setting and ALWAYS displays what is STORED in the database/GEDCOM file.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
Post Reply