Space Proposal

Skip to end of metadata
Go to start of metadata

Scope of change: Major
Champion Name: Evgeny Bogdanov
Spec Editors: Evgeny Bogdanov
Ref implementation: Apache Shindig 3.next

Background

Despite the fact that OpenSocial solves the problem of social media platform’s extensibility and gadgets portability, it has two major limitations. First, it is user-centric but does not take the user's context into account. In many social media platforms context is a crucial component and if gadgets were able to retrieve the user's context (from the hosting platform), it would greatly improve user’s experiences.

Conceptual changes

In the proposed extension a widget does not belong only to a person, it might belong to either a space or to a person. Such space or person we call the context. If a user is viewing another person's profile, then this profile is the context. If a user is viewing a space (a group, a community page, an event page, a course), then this space is the context. The opensocial's concept viewer is still valid here since only a person (not space) can view the widget. Though, the concept owner has to be redefined. Owner of a widget might be a space or a person in a sense that this widget belong to either a space or a person.

We suggest the word Space to be used. However, some other namings were proposed as well: "Community", "Group". We believe that the word Space covers broader area than "Community" or "Group" that are people centric. For example, event space or course space does not necessarily imply the community or a group of people.

Please refer to this paper on Contextual spaces for detailed information.

Difference between OpenSocial Space and Group

Space is a concept different from Group concept of OpenSocial.
Group is a way to tag people (collection of friends, relatives, etc). It is very similar to a circle concept of Google+. People in such group do not know that they are in the group, it is not the place shared with several members. Space represents another concept - a place where group of people gathered together for some activity: University course, collaborative project, event organization, discussion thread, etc. Every person in a space is aware about other participants. Imagine a group or an event on Facebook or discusion thread in google groups. If we add a gadget there it will be shared by people in that group or event. This is a Space concept.

Social graph clarification (Person vs Space)

Person
|-- his apps
|-- his connections (people with whom he is connected)
|-- his albums
|-- his activity streams
|-- his groups (friends, close friends, collegues)

Space
|-- its apps
|-- its connections (participants of a space)
|-- its albums
|-- its activity streams (actions within a space)
|-- its groups (members, admins, etc.)

Person can belong to different spaces.

APIs proposal

We provide here only JavaScript APIs with explanations to show what kind of requests are needed from widgets to work with spaces.
The initial proposal and first OpenSocial REST and JS APIs for Spaces can be found in the links section below. The APIs try to provide backward compatibility as much as posible.

Be aware that OpenSocial is planning to have IRI to identify resources.

0. security token (new)

Security token should contain the context information. Now it contains OWNER and VIEWER.

For spaces OWNER should be changed into CONTEXT, which would equal to a IRI for either space or person.

1. osapi.context (new)

osapi.context.get (alternatively, opensocial.getContext)

Gadget should be able to know whether it belongs to a space or to a person and their respective ids.
This API retrieves info about where widget lives

osapi.context.get().execute(function(context){
  context.id; // IRI id of the item
});

2. osapi.people

osapi.people.getViewer

Get user who looks at widget at the moment (Viewer)

osapi.people.getViewer().execute(function(viewer){
  viewer.id;
  viewer.displayName;
});

osapi.people.getOwner

Get owner of the widget
(new) For spaces: if viewer is the space owner it returns this viewer, if not owner - it returns any other owner of a space

osapi.people.getOwner().execute(function(owner){
  owner.id;
  owner.displayName;
});

osapi.people.get

(new) Get list of people (participants) in a space.

osapi.people.get({id: "http://example.org/spaces/18", groupId: "@self"}).execute(function(response){
  response[0].displayName;
});

Get space owners (or members)

Get list of owners in a space.

osapi.groups.get({id: "http://example.org/spaces/18"}).execute(function(groups){
  // groups[0].id - owners = "ID49"
  // groups[1].id - members = "ID50"
  osapi.people.get({groupId: groups[0].id}).execute(function(owners){
    owners[0].displayName; // owners of a space with id = "http://example.org/space/18"
  });
});

3. osapi.spaces (new)

osapi.spaces.get

(new) Get list of spaces for a person or for a space

osapi.spaces.get({id: "http://example.org/people/1"}).execute(function(response){
  response[0].displayName;
});

4. osapi.apps (new)

Such API should be introduced to OpenSocial. App-Id exists in OpenSocial but is never defined.
Also the identification for API should be revised. It is quite possible that user would like to add few
gadgets with the same URL on his page or to a space. Consider an example of an RSS gadget: a user adds two gadgets
with the same URL and sets different RSS links in different gadgets.

osapi.apps.get

(new) Get list of apps for a person or for a space

osapi.apps.get({id: "http://example.org/space/18"}).execute(function(response){
  response[0].displayName;
});

5. osapi.appdata

Appdata should be saved either for widget context (space or person where widget belongs) or per
any other user (viewer, for example).

osapi.appdata.update

Update/Save appdata for a space or for a person

osapi.appdata.update({id: "http://example.org/space/1",  data: {key: value}).execute(function(){
});

osapi.appdata.get

Get appdata from the container for a space or for a person

osapi.appdata.get({id: "http://example.org/space/1", keys: ['key']).execute(function(data){
  data['user1']['key'];
});

6. osapi.activitystreams

ActivityStreams can belong to a space or a person.

osapi.activitystreams.get

Retrieve activities of people within a space.

osapi.activitystreams.get({id: "http://example.org/space/1", count: 20}).execute(function(){
});

7. osapi.albums / osapi.mediaitems

Albums and mediaitems can be associated with a space or a person.
Once albums/mediaitems are replaces with CMIS's folders/files, the new API will be adapted accordingly.

osapi.albums.get

Retrieve albums existing in a space.

osapi.albums.get({id: "http://example.org/space/1"}).execute(function(){
});

8. osapi.groups

Groups represent a collection of people. They can exist for both a person (friends, collegues, etc) and a space (admins, owners, participants, viewers).

A Space can have many different groups. The groups can be created and deleted. Below is the list of generic (container-independent) groups for a space:

@members - all people who explicitely joined the space

@owners - space members with unlimited rights

@contributors - people who contribute content to the space (but less rights than owners)

@creator - the creator of a space

@followers & @following

osapi.groups.get

Retrieve groups existing in a space

osapi.groups.get({id: "http://example.org/space/1"}).execute(function(results){
  // results = [{id: "1", name: "members"},{id: "2", name: "owners"}]
});

Shindig patch with spaces

Shindig-2.0 is taken as a base: http://svn.apache.org/repos/asf/shindig/tags/shindig-project-2.0.0
Patch is attached (no tests!)

The patch is currently being moved to shindig trunk.

Links

Space proposal draft based on OpenSocial 2.0 spec

Space proposal patches for OpenSocial 2.0 spec

Reference implementation (Apache Shindig 3.0)

Old proposal from wiki.opensocial.org

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (1)

 

  1. Feb 17

    James Snell says:

    We are going through a detailed review of the proposal and will likely have much...

    We are going through a detailed review of the proposal and will likely have much more extensive comments later on, but these are just some initial thoughts that came to mind as I was reading through the proposal...

    1. In the Social API Server draft...
      1. Section 2.1.1.2 : The introduction of the context-id and context-type properties in the request is rather abrupt and underspecified. It's not clear given any of the spec text in this section what exactly those things are. Also, it's not clear at all how the group-id relates to the context-id. To be fair, the entire spec suffers from the same lack of clarity so it is in no way limited to the spaces proposal.
      2. Section 2.1.1.2.1: Under the description for the group-id it says, "The Group ID of the group of users related to User ID" ... I assume that should read "The Group ID of the group of users related to the Context-ID".
      3. Section 2.1.1.2.2: It would be helpful to have an example that shows retrieving the list of people for a space.
      4. Section 2.1.2.1: When using the create a relationship api to add a person to a space, it's not clear given the description what role the group-id parameter plays. Is that group-id relative to the user or the space? For instance, if my space has a @contributors group, and I want to add the user to that group within that space... is that what I'd use that group-id parameter for? That's what I assume but it needs to be made clear within the specification.
      5. Also in 2.1.2.1... what is the relationship between the group-id and the role a particular member has within the space? For instance, a space can have an owner, contributors, viewers, moderators, etc... each of these can be modeled as distinct groups or they can be viewed as forms of access control roles, which the spaces proposal currently does not appear to address. The proposal in general needs to clarify what a "group" is in terms of a space.
      6. I may have overlooked it, but I did not see a means of listing the groups associated with a space. To me, this seems like a major oversight, particularly with regards to spaces, especially since it is not clear how exactly groups relate to a space (e.g. see item [e] above)
      7. Section 2.1: The proposal modifies sections of the deprecated original activities text but does not seem to modify any of the new Activity Stream stuff in Section 2.5.
      8. Section 2.6: The proposal appears to make it possible to store AppData for a particular application in a particular space, but it does not appear to be capable of storing AppData for a particular user using a particular application in a particular space. For instance, I may use the same application with two separate spaces, with distinct AppData associated with each context. It's not clear given the description how that can be implemented.
      9. Section 2.6.3: The restriction against allowing appdata updates to arbitrary users makes perfect sense when dealing with user-specific AppData but I'm not sure if that carries through to spaces. For instance, if a space has @contributors group with it's own associated AppData, it's conceivable that any member of that contributors group or any members of an @owners group, etc could potentially be permitted to update that AppData.
      10. Personally, overall I would like to see a much more thorough and clarified treatment of AppData as it relates to Spaces.
      11. I note that context-id and context-type parameters are not defined for any of the other services in the document (albums, mediaitems, messages, etc). Why is that? Aren't those potentially tied to spaces as well?
    2. In the Social Data Draft:
      1. Section 2.8: It's not clear to me how all of the various properties defined for a space relate to the space. For instance, what is the meaning of the "images" array as it relates to the space? What about "ims"? "Interests"? The last I checked, none of my "spaces" has hobbies or passions. These fields appear to have been copied from the definition of the "Person" object but generally don't seem to apply to a Space. The definition here needs to be tied down significantly.That about covers my initial first pass review. I have not, as yet, had an opportunity to dig into the code patch but intend to next week.