There is a drastically enhanced Person object. Excellent (I love people). This is described in the Release Notes as Standardized profile information fields, which makes sense, so multiple applications can leverage the same data. Or at least that's what I thought until I saw the fields available, which include:
Body Type Fashion Heroes Scared Of Turn Ons
You get the idea. Each of these has a specific structure, such as a comma-delimited string, or in the case of Smoker an ENUM including the VALUES "socially" and "regularly." I wonder if anyone would want to target ads to smokers. Oh wait... they actually only added 3 specific ENUMs (which I would have added when I really care about accuracy of the data), which are DRINKER, SMOKER, and GENDER. From an ad-centric perspective, each of those ENUMs smell like money.
Now if I were adding applications into this fabric, I'd want to attach my own data structures that other applications could leverage off of the profile. For example, I think that iLike has a much better idea of the appropriate structure for music preferences than OpenSocial. How about letting applications defined sections within the user profile? Ever hear of metadata? Maybe custom properties?
Ironically, in the Enterprise, the social fabric has to be more open. Yes, it has to be more secure, since data can be sacrosanct, but the Sales Regions I Care About in a CRM system will have a structure that the CRM system needs to articulate, not some master system deciding it needs to be in a comma-delimited-format, or as an ENUM including Idaho.
We are excited about OpenSocial, but ask the same thing of it that others are: please be Open. Let applications define their own data shapes on the social graph. Allow more interesting sets of people emerge than "Friends." This is important for it to be relevant in our increasingly social, increasingly modern workplaces.
As we map these concepts to the enterprise, we will be doing just that. And we are very excited about the possibilities, as are our customers...