Revert person-name from given/sur(name) back to first/last(name) for industry compatibility.

[cdegroot-adobe]

What are the schemas that are affected by the issue

https://github.com/adobe/xdm/blob/master/schemas/context/person-name.schema.json

What are examples of products that are impacted by the issue

This will bring in greater alignment with the industries current norms, which are implemented and very hard to change. While it is agreed that Given Name and Surname are superior for representing names, it is not the way current systems work and there is no reasonable automatic way of translating between the two representations. XDM will be harder to adopt unless this change is made.

Examples of the first/last(name) usage:

1. https://github.com/Microsoft/CDM/blob/master/schemaDocuments/core/applicationCommon/foundationCommon/crmCommon/Contact.cdm.json
2. https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_objects_contact.htm
3. https://adobe-apiplatform.github.io/umapi-documentation/en/api/getUser.html
4. Gigia Profile https://developers.gigya.com/display/GD/Profile+REST
5. Facebook, twitter, linkedin, paypal, amazon.

Examples for given/sur(name):

1. International documents/passports
2. Governmental institutions

Examples of given/family(name):

1. W3C https://www.w3.org/International/questions/qa-personal-names
2. schema.org http://schema.org/Person

[cdegroot-adobe]

@kstreeter fyi, I am putting this back on the radar as an issue to resolve. Thanks C.

[trieloff]

You can add schema.org to the list of examples for given name: http://schema.org/Person

[cdegroot-adobe]

@trieloff it is actually worse then that. schema.org uses familyName rather than surName

E.g from http://schema.org/Person familyName | Text | Family name. In the U.S., the last name of an Person. This can be used along with givenName instead of the name property.

[kstreeter]

@cdegroot-adobe, @trieloff it definitely seems like there is no widely adopted norm on this, so we need to decide our own path. The W3C and schema.org seems the most considered to me. That would be my preference. We can ensure that the descriptions reference the alternative nomenclatures (first, last, surname).

[trieloff]

@kstreeter – agreed.

[cdegroot-adobe]

@kstreeter @trieloff - disagree. There is a very entrenched norm in our customers and the industry and that is to use firstname/last(name). W3C and Schema.org are leading thinkers in the way the world needs to go(at some point), but has not yet gone is any sizable way. Looking at implementation schemas of Campaign (set of ~110 customer databases) I see ~7 cases where there is a usage of surname, almost none using any form of familyname, they are all first/last(name), where surname is used there is a lot of use of first/last(Name), so they seem to be doing some dual usage. I do not know whey we want to go against the grain here considering one of our goals is data interoperability. The downsides are significant. If you want to keep given/sur(name) make a much more substantial case please.

[lrosenthol]

I would also favor W3C & schema.org on this one - even though it may differ from CDM.

[cdegroot-adobe]

@lrosenthol - please provide supporting evidence as to why you think this would be better.

The huge issue here is that there is no automatic way of translating between the two naming standards. first/last(name) is the standard in the world today, yes it is not ideal, but has been made to work in our customer's and Adobe's environments. XDM is to represent our customers data and they do not use the given/sur(name) in any appreciable way currently. So 100% of our Campaign customers will immediately create a custom first/last(name) and use that. So what is the argument of using given/sur(name) and causing customizations to be the standard here?

[lrosenthol]

How is this for a compromise, @cdegroot-adobe ?

For the xdm namespace, let's use first/last. BUT I believe we should also pre-define a schema.org namespaced version for those customers that wish to align with that. That way, we have both options for our customers, without the need for anything custom.

[kstreeter]

After spending a bit more time thinking about this one, I feel like perhaps what we should do is include both the first/last fields (to enhance compatibility with the various industry and Adobe apps that use this, as suggested by @cdegroot-adobe), and also include a "fullName" option. This is actually what the W3C recommends in the documents posted above, noting that there is simply no universally workable way to split a person's name into two parts.

This method would also be compatible with schema.org, which supports a full name (Thing#name) in additional to the given/family name fields. We can then encourage customers to use the full name method when the goal is internationalized support.

Would this also address you concerns @lrosenthol ?

[lrosenthol]

That sounds like a great compromise @kstreeter - thanks!!

[cdegroot-adobe]

@kstreeter yes, I support your proposal on first/last fields and a full name field. Thank you.

"fullName" is good as well as it aligns with Microsoft CDM (https://github.com/Microsoft/CDM/blob/master/schemaDocuments/core/applicationCommon/foundationCommon/crmCommon/Contact.cdm.json) modulo CDM use of all lowercase.

[trieloff]

After spending a bit more time thinking about this one, I feel like perhaps what we should do is include both the first/last fields (to enhance compatibility with the various industry and Adobe apps that use this, as suggested by @cdegroot-adobe), and also include a "fullName" option.

We do have xdm:name

The full name of the person, in writing order most commonly accepted in the language of the name.

[trieloff]

What would the three example names look like:

{
  "xdm:givenName": "John",
  "xdm:middleName": "S",
  "xdm:surname": "Doe"
}

{
  "xdm:givenName": "三",
  "xdm:surname": "张",
  "xdm:name": "张三"
}

{
  "xdm:givenName": "فلانة",
  "xdm:surname": "الفلانية",
  "xdm:name": "فلانة الفلانية"
}

[trieloff]

For European and North American names, the XDM approach is to simply treat givenName as firstName and surname as lastName – if you only have European and North American Names in your database, there is no adoption necessary.

My question is what our customers in Japan, in China, in UEA, in Israel are doing. Do they create custom fields? Do they just use first name/last name and then revert it in their templates like Hello <lastname>?

[kstreeter]

Hey @cdegroot-adobe , @lrosenthol I posted https://github.com/adobe/xdm/pull/215 to address this, please take a look.

[fmeschbe]

While discussions seem to have found a solution, let me post a comment by N. Anandhavelu as a FWIW (sorry for length, but I find it interesting):

TLDR of my longer answer:

1. givenName/surname is slightly superior because it makes no assumptions about position ( and may be number of parts).
2. Both don’t solve all problems.
3. Avoid assumptions about – character length, sharing last names between people and expanding initials.
4. Conversion between any two systems is tricky and not really automatic

Longer Answer:

What do we use : In our part of the world (a state in India with ~ 1% of world’s population) we use initials followed by name and no last name . Initials can be

1. First (or first few) alphabets of the father’s name . For example my name is N. Anandhavelu with N coming from my father’s name which is PON. Natarasan with PON coming from my grand dad’s name which is Ponnusamy ( I am skipping his initials ).
2. First (few) alphabet(s) of Father’s name and place name. My wife’s name is N.S. Sharmiladevi. N coming from Nagarasunallur – her village and S Coming from Shanmugham - her Dad’s name.
3. First (few) alphabet(s) of Father’s name and Mother’s name.
4. These are not very common but one can imagine any combination of first (few) alphabets of {father’s name, mother’s name, place name and grand parents’ name} becoming initials.

Example Conversion: My name is N. Anandhavelu. Initial is N , Name is Anandhavelu. First name is Anandhavelu , Last name is Natarajan. Given name is Anandhavelu, surname is Natarajan

Here are some of the problems I faced when I convert our initials system to First Name/Last Name system :

1. What goes as First Name ( Position Assumption):
   1. I think the correct first name for me is Anandhavelu and for my dad is Natarajan
   2. But many a times different things go into Firstname in systems and they cause headaches
      1. Example mistakes :
         1. Natarajan (or just N) is mistakenly added as first name for me ( Assumption – what is written first is the first name )
         2. Pon is mistakenly added as first name for my Dad. This is more common as most systems accept any word longer than 2 characters in the first and last name fields without asking for expansion. In no time, you have multiple systems one with expansion , one without , one uses Pon for first name and one uses it for last name.
         3. There are even more combinations of what goes into first, middle and last and what gets expanded in case of my wife’s name.
   3. At the XDM level, not making assumptions about positions is better. givenName/ surName solves this problem.
2. What goes as Middle Name ( Position Assumption)
   1. It is pretty common in other places ( even in most parts of India) to assume Father’s name as middle name. But I have used up my Father’s name for the Last name field.
   2. This has not caused major problems as you are always allowed to skip middle name.
3. Expansion of Initials
   1. Usually it is fine expanding / not expanding. As long as the system is aware/neutral to this aspect. String matching last names can be an issue.
   2. Example confusion – If my father enters PON as his last name , it is not known to the system if it is expanded or not.
   3. I am not sure how this can be solved at the XDM level completely. Atleast we should not be making character length assumptions.
4. Continuation of Last Name in family
   1. Some systems assume continuation of last name in family and cause problems. For example they expect my father’s last name and my last name to match.
   2. I would say the usage of the term familyName as against surname or lastname adds to this confusion.
   3. At the XDM level it would mean not sharing the last name/surName field between people.
5. Number of Fields
   1. First Name/Last Name assumes exactly two (or three) fields. It works for majority cases but fails for a good number of cases.
      1. In my case , it works as my name has two parts – ‘Anandhavelu’ and ‘Natarajan’. But in my wife’s name it becomes problematic – recollect that she has two letters in her initials– father’s name and place name.

My Comments:

1. Problems 1,2 and 5 are solved by givenName/surname system.
2. None of these problems stay within data model but get carried over to business logic. So a move to givenName/surname system will definitely cause more problems in the short run.
3. Problem 3 and 4 are not solved by any of the system. Problem 5 may not be solved by givenName/surname system if it makes any assumptions about number of parts.
4. I would bet that world will increasingly move towards givenName/surname ( and better) scheme(s) as we connect more and more people digitally.
5. I don’t imagine any system solving this issue fully – we should base it based on a long term vs short term trade off we want to make.

[trieloff]

What if we take a different approach:

• we keep name/fullName as a universal fall-back
• we introduce firstName/lastName as optional fields to ensure backwards compatibility with eurocentric database schemas
• we add a locale/language property (BCP47) to enable software to pick better names (i.e. if you want to greet someone informally in de_DE, try givenName, then firstName, then fullName, if you want to do the same in Japanese, try givenName, then lastName, then fullName)
• we keep the option of adding more language-specific fields like middleName later on.

[kstreeter]

I like the idea of having a locale, but I think we can capture that in other ways (location context, address, etc.)

I think what we are saying is that fullName is not a fallback: it is the preferred way to carry name information, since component names are not a reliable way to discern the details of a name. We will encourage use of this field, and are only providing first/last for legacy compatibility. If someone does have data as given/surname we would ask them to combine that directly into fullName.

[trieloff]

I like the idea of having a locale, but I think we can capture that in other ways (location context, address, etc.)

The advantage of having it right in the name is that we can deal better with people having multiple names (e.g. Xi Jinping, 习近平, 習近平) without inferring it from language preferences.

I think what we are saying is that fullName is not a fallback: it is the preferred way to carry name information, since component names are not a reliable way to discern the details of a name. We will encourage use of this field, and are only providing first/last for legacy compatibility.

Good. We need to cover this in the description.

I still think it can make sense to have more fine-grained component names, especially for use cases like personalized greeting messages. Depending on the context you want to be able to greet people as Kevin, as Mr Streeter, or as Kevin Streeter.

[cdegroot-adobe]

215 has been merged. Closing this issue.