Closed nilsbrummond closed 11 years ago
+1
+1
But see my comment in #161 about removing the lists of known Foo Types from the spec.
I presume we'll also be supporting Matronymic too then pls?
But see my comment in #161 about removing the lists of known Foo Types from the spec.
Not a bad idea consider the number of name types potentially. examaple: pull request #201
Supporting all cultures could be complex...
Separated specs for type enumerations, that could be faster moving, could be a good thing.
I presume we'll also be supporting Matronymic too then pls?
+1
Yup I need these too. Less common for me but I have a few.
To extend this concept further, should we then also include patronymic-surname and matronymic-surname types to separate the surname parts for Spanish and Portuguese names?
What about maiden-surname for females that use their maiden name as their "middle" name after marriage?
From a research perspective, it would be quite helpful to identify the etymology of a name part. However, if a name part can only have one "name part type" assigned to it, I worry about the impact of the _mis_use (not abuse) of these sub-types. I also am concerned about misinterpretation of automatic mappings in and out of systems that do not preserve these sub-types.
For instance, consider Jane Weston Johnson. The name Weston could be her
That name part can stored as a GIVEN name part in one system and a SURNAME in another system if these systems do not acknowledge the nuances of the sub-types.
Sorry I've rambled so much.
My main desire for the patronymic is to have a last name type that the software knows it does not make sense to group people by. A last name that changes every generation is just noise if put in a surname list.
To me the fact that a name-part is group-able, or not, is really what is important. There are a lot of cultural name rules and types out there. Enumerating then all is probably not feasible. perhaps a property set that can be applied to name-part-types when defined as needed.
My main desire for the patronymic is to have a last name type that the software knows it does not make sense to group people by. A last name that changes every generation is just noise if put in a surname list.
Turning this around is it not more important to identify the name parts which can be sorted by ... in other words instead of going into the intricacies of patronymic, matronymic etc etc just have a flag attribute on the name part for "include in index" or some-such?
Or thinking again maybe just have a text property of the Name (not Name part) which is simply "Index As"
Okay. It's my turn to jump in on this thread.
First, I believe the requirement for "name parts" comes from the fact that much of the genealogical data we deal with was collected via name part fields -- e.g., a death record with "Given name(s)" and "Surname" fields, or an Ancestry.com "Add..." form with "First and Middle Name", "Last Name" and "Suffix" fields -- and that it might be best to exchange that information in the form that it was collected rather than reformatting it. The reason the data was collected in parts was likely to facilitate sorting and searching by asking the informant to identify those parts, but sorting and searching are really outside the domain of data exchange and sort/search algorithm requirements should not be principle drivers in this conversation.
As I have considered the various ideas expressed here and elsewhere, I am starting to come to a idea that is different that any I have heard or seen expressed before. As Inigo Montoya says: "Let me 'splain."
It seems to me that it is useful to designate a name part as a "surname" even if it happens to be "patronymic" in construction. It is useful to designate a name part as a "given name" even if it happens to be the "religious" part of his given name. There seems to be a type hierarchy with the root of the hierarchy being very general with a desire to add a bit more detail.
Most applications define and use the notions represented by the most general designations (i.e., given name, surname). The additional qualifiers are rarer, but potentially useful. However, it does not seem to me that these qualifiers fit best as siblings to the most general designations. I do not think adding a "Patronymic" type as sibling to the "Surname" type is an improvement. Instead, it seems that "Patronymic" further describes or qualifies the type of "Surname" and that a name part could be both a surname and a patronymic name.
All of this suggests an implementation something like the following:
NamePart
NamePartType
http://gedcomx.org/Prefix
http://gedcomx.org/Given
http://gedcomx.org/Surname
http://gedcomx.org/Suffix
NamePartTypeQualifiers
http://gedcomx.org/Patronymic
http://gedcomx.org/Matronymic
http://gedcomx.org/Postnom
(see #201)http://gedcomx.org/Maiden
http://gedcomx.org/Family
http://gedcomx.org/Geographic
http://gedcomx.org/Occupatoinal
http://gedcomx.org/Religious
http://gedcomx.org/Familiar
http://gedcomx.org/Middle
I have been somewhat arbitrary in my selection of qualifiers, but wanted to give a sense of the possibilities. I think there is quite a bit of value in thinking of things in this way. Most existing data could be represented without a qualifier, but as people and algorithms became more sophisticated, these qualifications could be added and used and shared.
So what do you think?
Seems a good approach. Along the lines of dublin core's dumb down principle..
The only problem I have is the specific case of the Patronymic. Assuming Patronymic would be a NamePartTypeQualifiers applied to a Surname field. By default a Surname is an inherited family name, and names are generally grouped by Surname in software. If you dumb down from Patronymic to Surname you have the problem that the name goes from being logically ungroupable to groupable.
People with the same Surname are generally related in the same family tree. People with the same Patronymic name are not generally related. I.E. please don't sort Patronymic names into the Surname list.
Perhaps modify as such:
NamePartType
People with the same Surname are generally related in the same family tree. People with the same Patronymic name are not generally related. I.E. please don't sort Patronymic names into the Surname list.
So I think your proposal is to rename Surname
to be InheritedName
? I'd have concerns with that because Surname
is just so universally used. I understand that you can't assume a relationship between people with the same Patronymic
name, but that doesn't mean it's not a surname, does it? I think you've got a valid concern about the behavior of products, but I think those concerns fall outside the scope of this project. We're just trying to provide a way to exchange these kinds of data, not define how products behave.
Let me quote from that "universally accepted authority", <grin>, Wikipedia (Surname):
A surname is a name added to a given name and is part of a personal name. In many cases, a surname is a family name. Many dictionaries define "surname" as a synonym of "family name". ... The Icelandic system, formerly used in much of Scandinavia, does not use family names. A person's surname indicates the first name of the person's father (patronymic) or in some cases mother (matronymic).
[bold added]
Although one may usually consider a surname to be a family name, shared by the group members, it is not always the case. Patronymic and matronymic surnames are still surnames, and are used to affiliate the individual with a parent. It just so happens that their surnames are [usually] not the same.
I believe @thomast73 is proposing a very viable solution that addresses the aggregation of NamePartTypes
which allows the generic grouping of Suname
[in its various forms and meanings] and allows further clarification as to how that 'NamePart` may affiliate the individual with others of group.
From a potential processing perspective, this also has the benefit of providing "fuzzy logic" and probabilistic weight for those ambiguous Surname
terms that may be interpreted as a Middle' or 'Family
term in the GivenName
by one contributor and as a Maiden
term in the Surname
by a different contributor. Acknowledged, processing is out of the scope of GEDCOM X's charter.
So I think your proposal is to rename Surname to be InheritedName?
Yes it was, as well as add "Other".
I'd have concerns with that because Surname is just so universally used. I understand that you can't assume a relationship between people with the same Patronymic name, but that doesn't mean it's not a surname, does it?
Okay, I just read http://en.wikipedia.org/wiki/Surname and now agree with you. In my mind a Surname was an inherited Family name. According to the wiki page a Surname is a generic last name, family name, Patronymic, etc.. category. So I was wrong.
I revoke my proposal for Inherited and Other NamePartTypes.
I think you've got a valid concern about the behavior of products, but I think those concerns fall outside the scope of this project. We're just trying to provide a way to exchange these kinds of data, not define how products behave.
I agree to some extent, as long as the data needed for a product to behave well is included. I think we are close now that I understand Surname better.
From http://en.wikipedia.org/wiki/Surname :
In Spain and in most Spanish-speaking countries, the practice is for people to have two surnames. Usually, the first surname comes from the father and the second from the mother...
So be sure multiple name-parts with the type=Surname and TypeQualifiers=Family are allowed. I don't think there are prohibited.
Just thinking we may need to cookbook or good set of examples included for names to insure good data exchange.
Edit: @Daveyse - Didn't see your post till after I wrote mine...
From http://en.wikipedia.org/wiki/Surname :
In Spain and in most Spanish-speaking countries, the practice is for people to have two surnames. Usually, the first surname comes from the father and the second from the mother...
So be sure multiple name-parts with the type=Surname and TypeQualifiers=Family are allowed. I don't think there are prohibited.
This brings up the one other question I have in my mind.
Given the name "Diego Acuña Y Romero" and a cultural context of "es-Latn", we might consider a couple of different configurations for modeling it.
Method 1 (would require a change to my initial proposal -- qualifier[0..*]):
I think something like Method 1 would be a pretty good rendition -- very few assumptions need to be made.
Method 2:
The problem with Method 2 is that without the second qualifier, I cannot identify which name came from the mother and which came from the father. I can (using the information specified by the cultural context) make an assumption about it and be right a high percentage of the time; but it might be better if we could be a bit more explicit.
Method 3:
In Method 3, I would like to establish a qualifier for NamePart2, but what should it be? It is a family name, but really it is two family names. Assigning a qualifier using the above list seems to be a bit more sketchy.
Thoughts?
Oops! I must have hit the wrong button. I did not intend to close this.
I like the Type/Qualifier idea a lot. Some thoughts on how I would categorize names from my own tree:
- "Bette" Niels Christensen Dalsgaard (1831 - 1904):
- "Bette" (Prefix, Nickname) or? "Bette Niels" (Given, Nickname) -- "bette" meaning "li'l", as his older brother had the same given name, they were named after their grandfathers.
- Niels (Given).
- Christensen (Surname, Patronymic) -- after his father Christen Nielsen Dahlsgaard.
- Dalsgaard (Surname, Geographic) -- the farm he resided on; this is very common in older records, and many current family-surnames are derived from these.
How about
Method 1 - MODIFIED.
How about just delete NamePart3 as below, if unclassified? The full name text is still in the NameForm...
I think it would also be valid to include just a Surname parts, if so desired, to give minimal information for surname indexing. For the case where the researcher only cares about identifying the Surname.
How about just delete NamePart3 as below, if unclassified? The full name text is still in the NameForm...
I think it would also be valid to include just a Surname parts, if so desired, to give minimal information for surname indexing. For the case where the researcher only cares about identifying the Surname.
If you assumed that a full rendering of the name (with the 'Y' included) existed in the NameForm.fullText
value, it would be acceptable to only include in parts
the name parts that the application had classified and leave out any unclassified portions. But it may also be acceptable to build a parts
list that includes all terms in the full rendering of the name, including unclassified parts. Or it would also be acceptable to express the name by only providing parts
. It might not be such a good idea to only provide parts and leave out unclassified portions, however.
How about "Bette" (Prefix, Diminutive) "Niels" (Given)
Well, it's just like saying "Little Peter" and "Big Peter" to differentiate two men called Peter. "Diminutive" seems more fitting for qualifying "Betty" (as d. for "Elizabeth").
So rules for getting a full name would be as such?:
Only problem I see is multiple ways to present the same data. I personally prefer tightening the spec down to one way. Keeps thinks simple. Require NameForm.fullText to not be null is one way..
So rules for getting a full name would be as such?:
- If the NameForm.fullText field is not NULL then it is used.
- Else concatenate the NameParts in the order provided.
Only problem I see is multiple ways to present the same data. I personally prefer tightening the spec down to one way. Keeps thinks simple. Require NameForm.fullText to not be null is one way..
We are in the process of updating the specification. This comment would be better discussed on pull request #155. Would you please review the updates being proposed there and then re-comment as necessary? Thanks.
Please note that the proposal to address this request is attached to #155 and summarized by my comment. We'll leave the proposal uncommitted for a few days to allow people to comment before we merge.
Thanks, everyone, for your input on this issue. The changes we have made as a result of your feedback were merged into the master branch as part of pull request #155. We appreciate your time and thoughts and we feel that your feedback has helped to improve the GEDCOM X model.
Proposal:
Add a new NamePart known type of:
http://gedcomx.org/Patronymic
Support for pre-surname era of Scandinavia and other place using patronymic names. In the Scandinavian case the "last name" is in the form "<father's name's>-son" or "<father's name's>-daughter". Therefore unless the son has the same name as the father then the "last name" changes every generation.
References: http://en.wikipedia.org/wiki/Patronymic http://www.sorensenfamilyhistory.org/genealogy/danish_names_genealogy.htm