Project

General

Profile

API - Name data normalization

Added by Anonymous about 7 years ago

Splitting exist name data as first name/last name format since several shipping service providers force to use normalized input on their API's.

*Issue
- name data in BL DB has a lot of different kinds of format. (e.g. Chinese name, Arabic name)
- some are not saved as split format.

*Possible solutions
- Name data normaliztion on Seller side
Since denormalized data means a loss of information for seller, that is at best difficult at worst impossible to recover.

- Forcing to normalize name to Buyer


Replies (13)

RE: API - Name data normalization - Added by Anonymous about 7 years ago

I think, it is best, to let the users enter their data in an normalized fashion. If, e.g. someone has forename => Denis and surename => David there a many ways to enter it denormalized, like: "Denis David", "David, Denis", "David; Denis", "David Denis". Unfortunately, both names could be forename and surename. So there is literally no way to distinguish the names and you would need to run a time consuming manual task of gaining the additional knowledge, like giving the customer a phone call, and so on. So I am strongly convinced, that normalization on seller side is not feasible. The same is even more true and critical for address data, because there is no internationally unqique format for address data, so parsing would be very error prone.

RE: API - Name data normalization - Added by Anonymous about 7 years ago

I would propose:

The current name data ("Denis David") would be automatically in the "First name" field of the new data.

The new data would have:
First Name: Denis David
Last Name: [null]

Then when the buyer validates an order, a script would (always) control the validity of its personal data.
It would detect that the "Last Name" field is Null, and would force the buyer to check and worrect all his personal data.
It would be the same personal data page as when a new buyer registers, except it's filled with existing data.

First Name: Denis David
Last Name: [null]

... the buyer changes to:

First Name: Denis
Last Name: DAVID

... and then he can validate his personal data.

Note: I would recommand the Last name to be automatically translated in uppper case, to visually mark the difference

Sylvain

RE: API - Name data normalization - Added by Anonymous about 7 years ago

ACK with Sylvain, except that I would really do this data update only once, when a user signs in. I would not update the data within the order validation / checkout process, because that is already complicated enough, from both the usability and technical perspective.

RE: API - Name data normalization - Added by Anonymous about 7 years ago

At the Login, yes, good idea - except of course if the buyer logs at the very last moment, during the checkout...

RE: API - Name data normalization - Added by Anonymous about 7 years ago

Any discussions about names also need to include the fact that some names are reversed... I would suggest using the more correct terms of "Given Name" and "Surname", which is what Active Directory does. You can then have a full box that has "Display Name". For instance, for you Star Trek fans, there was a character named Kira Nerys. Kira was her Surname, Nerys was her Given Name. That allows folks to separate their names properly but also show it in the correct order.

- Eric

RE: API - Name data normalization - Added by Anonymous about 7 years ago

in the correct order.

There is no global correct order.
It seems to me then in Asia they often have a reversed (for us) name order: LastName FirstName.
And I'm not sure either it's polite (or common) to, for example, start an email using "Dear FirstName,"
...

Anyway, if we may need name formatting, I guess it's only for shipping purpose, when DHL or Fedex would require you to have a mandatory "LastName" field?

In short, what seems to me important is to separate well the "LastName" of the other fields. We don't really care for First, Given, Middle or any others names.

For the buyers, it may be explicited, like:

Last Name(s): [ ] <== Important, please enter here only your Last name(s) (or Family name, Surname)

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

It seems that our only option is to have a new database model.

However, since we are in the middle of checking overall structure of BL DB, so we try not to change database from as it is now.

We will definately make new colum for name data in the future and will collect normalized data from users like Junam said in the email on 24th, Oct.
e.g. during the check out if user has null information in either Given Name or Surname field, we will ask them to submit right information.

Also my question is,
What happen if you use null info for shipping service providers' API? and how do you deal with it for now?

Hyoeun

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

Hi Hyoeun,

It depends on the shipping service. Although its deprecated, the Internetmarke service for sending letters, allows to use a multiline text field as address for a reduced set of functionality. The DHL Intraship API for packages needs normalized name and address data as input and fails with error on null values. So the current workaround is not to use the API but to manually print DHL labels with the address data.

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

@Hyoeun: for us it's not a problem, we don't need name normalization - it would be nice, that's all.

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

@Sylvain : thank you. what I meant was it's tough for us now but we will plan to do it later! will keep you all updated regarding this.

Also want to ask you all one more thing, Sylvain mentioned it above reply but still want to make sure.
where else you can use this normalized name data except for shipping providers?

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

@Hyoeun - See your case is interesting. Due to probably usual contacts with Western, you reversed the traditional order of your name.
In short, for some names it's impossible to be sure what is the first name and the family name... It would be interesting to know this so we can write emails to our buyers:

Dear John, (first name, casual)

Dear Mr. Park, (last name, polite)

This can be used at the checkout also...
"Thank you John! Please now confirm your order selecting the shipping method..."

I would see also some database search and/or comparison, even for BrickLink: is this user "John Martin" not the same as "Martin John" ?

I don't see any other usage (apart shipping) for this normalization.

Hoping that helps?

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

It may also be, that the german customs API need normalized names data. Unfortunately I could not verify yet, because getting the documentation has some uncomfy obstacles.

Another important point is, that the professional sellers may want to connect an ERP or other kind of management system of their choice to the new API to ease their workflows. It's likely, that their systems will internally use normalized data, so all those systems will be hard to connect.

RE: API - Name data normalization - Added by Anonymous almost 7 years ago

Thank you for all your opinions! Our team came to the conclusion on this API.

As I shared in prior post, API regarding name data will be provided as denormalized version for now.

However, we will try to finish the development for normalized data until around end of this year(2013).
Details :
1. Add new DB field for normalized data.
2. For Sellers who want normalized data, we will provide a pop-up feature which buyers can submit their normalized data during the check out.

If you need further information, please let us know!

Hyoeun

    (1-13/13)
    Add picture from clipboard (Maximum size: 24.4 MB)