Additional group models

In OpenSocial, the "group" capability effectively represents a shortcut for social graph navigation. This should not be confused with a formal group construct that is in many social business platforms, e.g. Jive calls these "social group".

This proposal takes the additional constructs for social group navigation that are present in Jive and standardizes them in the specification. Specifically, we are proposing:

Helper Groups

@all : Returns the entire set of information for the user. This avoids having to go to get the @supportedFields and construct a query

@summary : Returns a summary of the person.

Organization Chart

@manager : Returns the requested user's manager.

@reports : Returns the list of people that report to a the user.

@colleagues : Returns the list of people with the same manager as the user

Improved Relationships

Many social systems today make a distinction between uni-directional and bidirectional relationships. OpenSocial, should adopt the semantics of one-way relationships

@following : The collection of OpenSocial people that the user is following. These are not necessarily following the user.

@followers : The collection of OpenSocial people that are following the user.

The intersection of @following and @followers should be @friends.

Proposal: Group ID Registry

We should treat Group IDs in a manner similar to other kinds of label-type extension points (e.g. link relations) and have a Registry of Common Group IDs. We would define an initial collection of well-known group identifiers (e.g. @self, @all, @summary, @manager, etc) and define their specific meaning within OpenSocial applications. Implementations would be free to implement the specific group ID's they need, as well as define additional group ID's as needed. When id's become common in use, they can be added to the registry. The Registry would be maintained on the OpenSocial Wiki.