Spaces Proposal

[Mark W.]

Laurent,

I've seen a couple of posts recently on starting to think about spaces again now that we've got 2.0 done. A couple of questions.... What's the latest status on this proposal and would you be willing to walk some of us through it in more detail on one of our calls?

Thanks!

[Henry Saputra]

Mark,

I think Evgeny is the champion for the previous Space proposal for OS spec:
http://docs.opensocial.org/display/OSD/Space+Proposal

- Henry

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/AwMfM_-ZK8MJ.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>

[Evgeny Bogdanov]

Hi Mark,

Since we decided to extract space proposal from OS 2.0 draft and move it to OS 2.1,
I did work quite a lot with container implementation and few widgets that use this concept.
More precisely, we have implementation for 3 different containers now plus several gadgets that use the concept.
It seems to work smoothly.

While doing this, I learned a few things that made me revise the initial proposal.
So now I plan to add revisions into proposal (asap) and then we can start discussing
the newest version.

I will keep you posted (I hope to work on it next week).

Best
Evgeny

[Niels van Dijk]

Hi Evgeny,

Sounds very good! Any code we can have a look at, e.g. for Shindig?

Cheers,
Niels

> --
> You received this message because you are subscribed to the Google
> Groups "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/qEwQ1Grd4kQJ.

[Evgeny Bogdanov]

I will append a patch file for shindig 2.0 (did not try it for new shindig yet)
once it is cleaned up.

[Evgeny Bogdanov]

I updated the spaces proposal and attached the patch for Shindig-2.0 (no tests yet).

http://docs.opensocial.org/display/OSD/Space+Proposal

Best

Evgeny

[Evgeny Bogdanov]

Any thoughts on the space proposal??

App and Context end-points ...

http://docs.opensocial.org/display/OSD/Space+Proposal

[Troy A. Griffitts]

Hey Evgeny,

Just read through the space proposal. I sympathize with your need. I have a need to sometimes store appdata per:

1) site-viewer

Use case:
John transcribes a manuscript in the Transcription Gadget and saves his work. The Work Summary gadget needs to display his saved but yet-unsubmitted work.

2) site-gadget-viewer

Use case:
User tags manuscripts as 'favorites' in the Manuscript Catalog Gadget. He wants to see his favorites no matter what page he finds the Manuscript Catalog Gadget.

3) site-page-gadget

Use case:
This is your suggestion to use appdata as configuration storage: When an owner drops a gadget on a page and configures it for a specific purpose for all viewers.

4) site-page-gadget-viewer

Use case:
A user is indexing a manuscript with the Indexing Gadget on the Indexing page. He stops on Tuesday, and when he comes back to the Indexing page on Thursday, we'd like to take him back to the page where he left off.

I am only wary about introducing a new concept that isn't obvious to new users. Instead of owner/viewer/'space', aren't we simply adding 'scope' to appdata? If we add 'scope' then this would make adding new scopes easier for new scenarios in the future without changing method signatures.

This is my first read of the space proposal. I hope I haven't missed something. I certainly sympathize with the need for a change.

Troy

> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/rzQu5Jpi4BYJ.

[Evgeny Bogdanov]

Well,

I am not sure I understand what you mean by scope.
AppData belongs to somebody - to a person or a collection of people.
Space represents such collection of people. Things within a space are shared by these people.

So if AppData belongs to a space, it means it belongs to all these people simultaneously.
Space is not about adding a scope to appdata, but rather represent a new concept
that is used everywhere but does not exist yet in OpenSocial.

It is a shared collaborative place for several people, that has its list of widgets,
resources. A university course for example. To have appdata saved for a space
is rather a consequence than the main reason for a space introduction.

Evgeny

[Mark W.]

Evgeny,

There are a number of things that interest me in this proposal. I think first and foremost, it's the idea that apps (I'd like to stop calling them gadgets) can belong to a space. This is something that is on the roadmap for jive and I'd like to do this in a way that:

1) Lines up with OpenSocial

2) Provides a base implementation in shindig--the fact you've got a patch there is awesome!! I've copied Henry on this post. Henry, is there a way to get this into extras but require a configuration change to actually bind it in?

Some questions though, on the proposal itself...

Can/should we line up the security token with some of the OAuth2 work? 

osapi.context

Should this be in opensocial? For example, we've got the opensocial.getEnvironment(), so maybe it makes more sense for this to be opensocial.getContext. Maybe the larger point is that we have osapi for the services and opensocial for reflection/discovery. What do you think?

osapi.getViewer()

We've already have this method. What's different about this in spaces?

osapi.getOwner()

This should return a single owner or a collection of owners.

Also, is there a concept of "Roles", e.g. I can be an admin of a space, but not an owner of a space?

I *really* like the app data stuff.

OK...

If we look at the existing opensocial API, it seems we'd want to introduce a new service, "spaces" (or something like that).

We may also want to introduce a new service "apps".

You'd then get a "space" and have...

space.getOwners();

One final note....

We'll need to address a couple of other things in here:

1) Identity. 

2) CRUD - especiall the Delete

3) Other things a space can contain besids apps. In Jive, for example, spaces have an activity stream. How do we model that?

This would be more consistent with what we've got today.

Make sense?

Overall, I'm very excited about this and would love to see it happen. I'd say let's keep working on this and target it for OS 3.0.

Thoughts??

[Helen Chen]

So, "space" will be a new data type, a collection of data including apps, resources and activity streams. And it should have similar attributes as apps and resources as well. Could the owner of a space be a group?

Regards,
Helen

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/Fx-43Nuvyt8J.

[Ryan Baxter]

Egveny great stuff.  I also think this is very importnat.  From an IBM
Connections perspective a space maps to a community and this proposal
takes a huge step towards representing a community in OpenSocial.

I agree with mark on the ActivityStream point, a space should also be
able to have an activity stream associated with it.

Thinking further into the future we should also consider files
associated with a specific space. IDK if a space should map to a
specific repository or folder, but we can certainly think about having
files associated only with a certain space.

[Evgeny Bogdanov]

Some explanations and answers are below:

> Gadgets -> apps

Agree fully! Google gadgets are now OpenSocial gadgets. We should start calling them

OpenSocial apps.

> Can/should we line up the security token with some of the OAuth2 work?

I don't know how these two are connected. If they are, we should.

> getViewer, getOwner, osapi.context.

Well, the thing is currently in OpenSocial an app lives on a user page. This user (or user page) is the app's owner.

This user is at the same time an owner and the context for the app. All the others people are viewers.

If we add space to the mix, an app can live on a space's page. So we need an API to get such context.

Probably, opensocial.getContext would work.

1. osapi.people.getViewer api does not change (works for both people and spaces)

2. osapi.people.getOwner returns the app's owner. For people case there is not problem. To make sure it does not break in an app that is on a space page, it should return something for spaces as well. This is why I suggest this api  to support backward compatibility.

The following code would work in all cases. 

if currentUser.id == osapi.people.getOwner.id

  displayFieldOnlyOwnerCanEdit

  

> Space owners and roles

There was a suggestion to apply an OpenSocial Group concept to space, which models basically the roles.

Groups (admins, owners, participants) would work just fine.

> Space and CRUD

There are all crud actions described in the spec patch to OS2.0, that I will be revising now.

I tried to put into the proposal only the core things to grasp the main ideas.

> Space and things around

In addition to apps space might contain files/folders from CMIS that are supposed to replace albums/mediaItems. And yes, space will have an activity stream associated with it.

I have added these things into proposal to have a better overview.

[Niels van Dijk]

On 12/01/2011 11:07 AM, Evgeny Bogdanov wrote:
> > Space owners and roles
> There was a suggestion to apply an OpenSocial Group concept to space,
> which models basically the roles.
> Groups (admins, owners, participants) would work just fine.

Hi all,

I've expressed earlier our interest in spaces as well. We would very
much like to use this for setting up collaboration spaces. From what
Evgeny states above and what e.g. MarkW already expressed, I strongly
feel we should also investigate if we can make groups 'first class
citizens' in OpenSocial as part of the Spaces implementation. No serious
implementation outside of the Social network field can live with only
'friends' as a group.

We indeed need colleagues, bosses, marketing, admins, classes, courses,
teachers etc. Next to that we need roles, so that gadgets and REST API
clients can make AuthZ decisions. I would argue however that we should
not use groups as suggested above where the groups are generic: a
specific space will have (a number of) admins, owners, participants,
etc, but a learning or collab platform will have multiple spaces, so a a
generic 'admins' group is most likely not going to work. I would
therefor suggest the roles should be on a per group basis, as was
suggested in the VOOT specification
(https://github.com/andreassolberg/voot/wiki/Protocol) earlier on this list.

This would model to something like this:

SPACE X
\__ Group 1
\__ Person a
\__ Role: admin
\__Person b
\_ Role: user
\__ Group 2
\__ Person c

This would allow groups to be members of different spaces, and would
allow persons to have different roles in different groups.

Cheers,
Niels

[Niels van Dijk]

Hi

On 12/01/2011 12:14 AM, Helen Chen wrote:

So, "space" will be a new data type, a collection of data including apps, resources and activity streams. And it should have similar attributes as apps and resources as well. Could the owner of a space be a group?

I would suggest that both persons as well as groups could be included in the collection of a Space. That would allow the sharing of a Space  inbetween containers.

It would be vary valuable to have a the ability to make a group the owner of a space. We have seen many times over hat the admin of a collab space leave an organization then orphaning the space. A group as owner could a solution to this.

This would however also imply the ability to e.g. have messages and activities targeted at groups the activitystram of a space should then I guess address the group.

Cheers,
Niels

[Evgeny Bogdanov]

Updates on Space.

I moved the Space spec from old OpenSocial tag and applied it to the the current trunk.

Applications are renamed to Apps

osapi.context -> opensocial.getContext

osapi requests are added.

You can find and view my version of trunk with spaces here:

http://iamac71.epfl.ch/os_space/

The initial proposal is here:
http://docs.opensocial.org/display/OSD/Space+Proposal

What concerns the other APIs (osapi.people/appdata/activitystreams),

we should decide if we need to replace userId with a pair (contextId,contextType), 

or we can just add (contextId,contextType) to userId to enforce backward compatibility.

Thoughts?

Adding groups to Space.

Would be nice to hear constructive suggestions how to add/define groups to the mix.

There was one suggestion. I think we elaborate more on the scenarios of use.

We normally use two levels (space owner and space viewer).

[Evgeny Bogdanov]

Groups and spaces.

There are several discussions going on the groups/spaces.

I believe group for a space should be defined similarly to groups for people.

Groups is a way to group people within some context. Divide person's friends into groups. Divide space participants into groups. 

What do you think about the following mapping?

Person

|-- all friends

|-- relatives

|-- collegues

|-- ...

Space

|-- admins/owners

|-- members

|-- followers

|-- ...

The relation between person and a space/person should be two-directional (friendship, membership) or uni-directional (following, followed). Do we need to have a predefined set of default groups for space/person or everything is up to the container?

[Ryan Baxter]

I think admin/owners and members would be good ones to start with. I
am unsure about followers, because following is not a concept we have
today in the spec....

[Mark W.]

It's not in the spec today, but it's one of the things that is on my plate to add. In jive, we've got the concept of following/followers. I *think* connections does as well. It's be great if we can standardize on these. It would work into the spaces stuff as well.

[Evgeny Bogdanov]

Well, it seem as it is there virtually:

Containers MAY support request to create a new relationships between users. This is a generalization of many use cases including invitation, and contact creation. Containers MAY require a dual opt-in process before the friend record appears in the collection, and in this case SHOULD return a 202 Accepted response, indicating that the request is 'in flight' and may or may not be ultimately successful.

Friends/Space member is bi-directional (requires two sides confirmation), while following/followers is uni-directional (no confirmation is required). I think with small effort it is possible to make it clear in the spec and than it is up to the containers to implement it.

[Evgeny Bogdanov]

I updated the proposal space trying to clarify the groups.

http://docs.opensocial.org/display/OSD/Space+Proposal

feedback is welcome!

[James M Snell]

I have posted some feedback in the comments area of the wiki page.
This is just based on my initial first pass review of the actual spec
language.

As for the relationship between Groups and Spaces, I would argue that
the definition of groups is largely arbitrary and very specific to the
type of space. We should not attempt to come up with a single
canonicalized list. Rather, we need to make it possible to
create/manage the groups available in relation to a space (or allow
the implementation to decide the available groups based on the type of
space) and provide an api for enumerating the groups available to a
particular space. That way, if one implementation supports a
@followers group but another does not, it's perfectly acceptable.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/oUSPE8rRXCAJ.

[Evgeny V. Bogdanov]

Yes James.
I completely with you on it!

[Mark W.]

I'm not sure I agree with you guys on this one. Let me try to explain it this way and see if it makes sense....

The way groups are now they are much more of a social graph "navigation" tool. That is @friends gives me a collection of MY social graph. Today, you can have any number of groups that you want, you just can't prefix them with "@". So I could have a group named "foo", but I should not use @foo.

That said, I think there are a number of new @groups we should support, specifically, @followers, @following, @manager, @reports, @colleagues. These are concepts that are found in either (or both) consumer facing social networks or enterprise social networks. 

(See:http://docs.opensocial.org/display/OSD/Additional+group+models)

So I agree with James that groups are largely arbitrary and we should not try to come up with a complete list. But we should recognize and standardize those that are very common and already appear "in the wild" today.

[James M Snell]

Assuming that it's handled in the same basic vein as AS object types
and Link relation types and other similar types of label concepts, I
agree. That is, what we'd be specifying is a limited, common core set
of labels with specific meanings while leaving it up to
implementations as to whether additional labels can be added (perhaps
even allowing for a registry of labels to be created within the
opensocial wiki). I'd be all for that. It should be entirely up to the
implementation which labels to support, tho, including whether or not
to support any of the core common ones we define... thus the need for
some mechanism for discovering which groups are available for a given
resource. The language describing the group "labels" within the spec
would need to be pretty significantly updated to reflect that
approach.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/VQdUDPHtzcQJ.

[Evgeny V. Bogdanov]

Any ideas what would be the list of groups for spaces?
@owners, @members ?

[Mark W.]

+1 on @owners

+1 on @members (these are people who have explicitly joined the space) 

I also think spaces can have @followers & @following

[James M Snell]

Just off the top of my head...

@creator => redirect back to the user that created the space
@contributors => distinct from @owners, subset of @members who
contribute content to the space

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/UGWTBQOtvmsJ.

[Evgeny Bogdanov]

Hi James,

thanks a lot for the extended review.

The answers are inline.

1. 1. Improved! 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. Fixed! 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. Added! 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. Improved! 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. Improved. Group definition is revised! 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. (f,g,k - not in spec yet, but listed here: http://docs.opensocial.org/display/OSD/Space+Proposal) 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. (h,i,j - the same gadget.xml will have different AppId in different spaces, you can even have several instances of the same rss.xml gadget in one space. About a particular user: I m not sure what is the best way to do it. In a rating widget for example, we save rating of users as appdataForSpace1App1 = {user1: rating, user2: rating} ) 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. (Space: Computer science lab, it might have images (logos) for it, topics of interest (parallel calculations), etc. Though of course we might get rid of it. When I copied Space from Person object I just left the things that might be somehow used for space. Should I remove them?) 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. 

[Evgeny Bogdanov]

I reworked some of the things for spaces in the spec according to the James' suggestions.

I also started to move the patch I had for shindig-2.0 to current shindig trunk.
Since a Gadget should be able to know whether it belongs to a space or to a person and their respective ids,
we need an API for it. Without spaces gadget lives on a page of its owner,
so osapi.people.getOwner was a solution.

To support spaces I created and end-point to get these data (see http://docs.opensocial.org/display/OSD/Space+Proposal)
osapi.context.get

Then the following API was suggested by Mark: opensocial.getContext
The question is which one should I use?