Formatted vs structured names and addresses

[Gyorgy Abonyi]

In version 3 we introduced structured names and addresses along with the formatted versions, however at the moment we do not provide conversion from formatted to structured at our side. Moreover the behavior of Contact Manager in GMail is suboptimal, only the formatted version can be edited, and upon edit of the name or address field the structure is destroyed. We are working hard to improve the current behavior.

We are intend to introduce heuristic name and address parsing in the API, and to help developers to adjust to incoming improvements we recommend to follow a few simple rules while developing structured and/or formatted data aware clients:

1. Read the flavor (structured / formatted) the client is interested about.
2. If the data type (structured / formatted) your client is interested in is not available, then format or parse the other available data type for the application needs.
3. On modification explicitly clear the flavor the application doesn't need. In this case mutation will trigger heuristics to generate the missing flavor.
4. If the application provides both structured and formatted parts no heuristics will be applied and data will be stored as is.

Please note that point 2 is a temporary solution until not all flavors are available in the database. As we intend to back-fill all existing contacts with the missing flavors using our heuristic parsers, this step will become obsolete in the future. Those contacts that already contain both flavors will remain unchanged.

Our heuristic parser will be used by Contact Manager in GMail too, so if the user edits the formatted name or address in the contact manager, we will generate the correspondent structured components.

And to answer your obvious question, when will it happen? As soon as we are convinced that our parsing algorithm is right. Please expect that the heuristic name parsing probably will come earlier than address parsing.

Hope this answers lots of your questions and valuable comments about formatted vs. structured names and addresses posted to this group.

Sincerely yours,
Gyorgy Abonyi, Google Contacts team

 

[Charlie Wood]

Gyorgy-

Thanks for the detailed information. Is point #3 needed though?

> 3. On modification explicitly clear the flavor the application doesn't

> need. In this case mutation will trigger heuristics to generate the missing
> flavor.

The current behavior seems to be that if I insert new structured data,
Google will create the formatted version for me without my needing to
clear the formatted field.

Also, I'm skeptical that your parsing algorithm can ever be "right".
Names are ambiguous. If a contact has the formatted name "Kramer", is
a first or last name? It's impossible to know. The only "right"
solution IMHO would be to expose only structured fields in the Gmail
Contact Manager. I hope that happens!

Thanks again,
Charlie
Spanning Sync

On Aug 5, 9:53 am, Gyorgy Abonyi <g...@google.com> wrote:
> In version 3 we introduced structured names and addresses along with the
> formatted versions, however at the moment we do not provide conversion from
> formatted to structured at our side. Moreover the behavior of Contact
> Manager in GMail is suboptimal, only the formatted version can be edited,
> and upon edit of the name or address field the structure is destroyed. We
> are working hard to improve the current behavior.
>
> We are intend to introduce heuristic name and address parsing in the API,
> and to help developers to adjust to incoming improvements we recommend to
> follow a few simple rules while developing structured and/or formatted data
> aware clients:
>

>    1. Read the flavor (structured / formatted) the client is interested
>    about.
>    2. If the data type (structured / formatted) your client is interested in

>    is not available, then format or parse the other available data type for the
>    application needs.

>    3. On modification explicitly clear the flavor the application doesn't

>    need. In this case mutation will trigger heuristics to generate the missing
>    flavor.

>    4. If the application provides both structured and formatted parts no

[Gyorgy Abonyi]

Hi Charlie,

Yes we currently create the formatted version if the client writes only the structured flavor, but not in the other way. If a client writes both flavors we store both flavors as is, without triggering any conversion. So in terms of conversion from structured flavor to formatted one, there will be no change compared to the current behavior.

And yes I ought to write "right enough" heuristic parsing, it's indeed not trivial.

regards,
Gyorgy

[Charlie Wood]

OK, got it--thanks for the clarification.

You know, I don't know how practical this is, but it would make the
world a better place if Google could open-source your heuristic parser
once it's finished. This is one of those problems that has been around
forever, keeps getting solved badly, and could really use a canonical
open-source solution. (If you do it, I'll translate it into PHP! :)

Thanks,
Charlie