Today, Yahoo! announced the public availability of their own Address Book API. Though Plaxo and LinkedIn have been using this API behind the scenes for a short while, today marks the first time the API is available for anyone who registers for an App ID to make use of the bi-directional protocol.
The API is shielded behind Yahoo! proprietary BBAuth protocol, which obviates the need to request Yahoo! member credentials at the time of import initiation, as seen in this screenshot from LinkedIn (from April):
Now, like Joseph, I applaud the release of this API, as it provides one more means for individuals to have utter control and access to their friends, colleagues and contacts using a robust protocol.
However, I have to lament yet more needless reinvention of contact schema. Why is this a problem? Well, as I pointed out about Facebook’s approach to developing their own platform methods and formats, having to write and debug against yet another contact schema makes the “tax” of adding support for contact syncing and export increasingly onerous for sites and web services that want to better serve their customers by letting them host and maintain their address book elsewhere.
This isn’t just a problem that I have with Yahoo!. It’s something that I encountered last November with the SREG and proposed Attribute Exchange profile definition. And yet again when Google announced their Contacts API. And then again when Microsoft released theirs! Over and over again we’re seeing better ways of fighting the password anti-pattern flow of inviting friends to new social services, but having to implement support for countless contact schemas. What we need is one common contacts interchange format and I strongly suggest that it inherit from vcard with allowances or extension points for contemporary trends in social networking profile data.
I’ve gone ahead and whipped up a comparison matrix between the primary contact schemas to demonstrate the mess we’re in.
Below, I have a subset of the complete matrix to give you a sense for where we’re at with OpenSocial (né GData), Yahoo Address Book API and Microsoft’s Windows Live Contacts API, and include vcard (RFC 2426) as the cardinal format towards which subsequent schemas should converge:
| vcard | OpenSocial 0.8 | Windows Live Contacts API | Yahoo Address Book API | |
|---|---|---|---|---|
| UID | uid url | id | cid | cid |
| Nickname | nickname | nickname | NickName | nickname |
| Full Name | n or fn | name | NameTitle, FirstName, MiddleName, LastName, Suffix | name |
| First name | n (given-name) | given_name | FirstName | name (first) |
| Last name | n (family-name) | family_name | LastName | name (last) |
| Birthday | bday | date_of_birth | Birthdate | birthday (day, month, year) |
| Anniversary | Anniversary | anniversary (day, month, year) | ||
| Gender | gender | gender | gender | |
| Email (ID, EmailType, Address, IsIMEnabled, IsDefault) | ||||
| Street | street-address | street-address | StreetLine | street |
| Postal Code | postal-code | postal-code | PostalCode | zip |
| City | locality | locality | ||
| State | region | region | PrimaryCity | state |
| Country | country-name | country | CountryRegion | country |
| Latitutude | geo (latitude) | latitude | latitude | |
| Longitude | geo (longitude) | longitude | longitude | |
| Language | N/A | N/A | ||
| Phone | tel (type, value) | phone (number, type) | Phone (ID, PhoneType, Number, IsIMEnabled, IsDefault) | phone |
| Timezone | tz | time_zone | TimeZone | N/A |
| Photo | photo | thumbnail_url | N/A | |
| Company | org | organization.name | CompanyName | company |
| Job Title | title, role | organization.title | JobTitle | jobtitle |
| Biography | note | about_me | notes | |
| URL | url | url | URI (ID, URIType, Name, Address) | link |
| Category | category, rel-tag | tags | Tag (ID, Name, ContactIDs) |
Factory Joe 