Opensocial V2 proposal: space extension

[Evgeny V. Bogdanov]

Hello,

We (our research lab at EPFL, Lausanne and I) would like to propose and contribute
to the Space extension for Opensocial V2.

Scope of change: Large
Reference to existing standard (if applicable)
Champion Name: space (or group)
Specification editor names and declarations of time commitment: Evgeny Bogdanov

We think that opensocial can be improved by providing a standard specification
not only in a people-focused way but also in a contextual space (or group) way.

Currently, person is a focal point and opensocial allows to retrieve friends of person,
his gadgets, his albums.

The groups of people are becoming an important part of social life.
Blogs, Google groups, facebook groups, etc. represent such contextual spaces with
list of members, list of albums/videos/resources, gadgets.
We think that by providing an extension to opensocial for spaces (groups)
might improve the openness for social networks.

Please let me know if you find such extension doable and useful for opensocial.

Best regards,
Evgeny Bogdanov
PS: In the attachement one could find the paper describing the usefullness
of these contextual spaces and how opensocial can be extended to support spaces.
Paper is accepted to ACHI conference but not yet published.

[Niels van Dijk]

Hi Evgeny,

Interesting proposal!
We seem to have been thinking along similar lines. Please have a look at
the work we did for COIN/SURFconext at
<http://projectcoin.surfnet.nl/2010/10/fifth-and-final-sprint-of-the-coin-project/>
This has a link to a video demo of the portal we created for the Dutch
Research and Education community which captures many of the ideas you
described in you paper, especially the ability to use group contect to
make gadgets behave more intelligent as soon as these are aware of group
membership. We also have some gadgets that dynamically change behavior
as soon as a group context is added. e.g switch from showing groups a
user is a member of to showing the members of a specific group.

We use group context to create what you call a 'space' - in our case
presented as a 'tab' - that can hold a set of coherent gadgets and
applications that groups can then use for collaboration scenarios within
R&E. One thing we support is the ablity for a user to 'share' the entire
space or tab with the entire group at once, making it very easy to share
a coherent set of gadgets with a group or team.

I'd be interested to learn if you feel this is what you are thinking
about. Note though, that most of the conext logic is curently handled by
the portal, and not, as you propose, part of the API itself.

Cheers,
Niels

[rbaxter85]

This is very interesting and I think it is a great idea. We
personally will have a use for this "spaces" concept as we have
several different contextes inside the same applications where you may
return different results when getting a users friends.

I also have a proposal where "context" is important. I am not sure
whether its the same concept though. In my proposal for embedded
experiences a gadget asks for it's context and that determines what it
will render. For example, you may have a gadget that renders YouTube
videos and based on the context it would render different videos. The
other difference is that the service, in this case YouTube, tells the
container what the gadgets context should be. Here is the proposal
http://wiki.opensocial.org/index.php?title=Embedded_Experiences.

On Dec 20, 3:19 pm, Niels van Dijk <niels.vand...@surfnet.nl> wrote:
> Hi Evgeny,
>
> Interesting proposal!
> We seem to have been thinking along similar lines. Please have a look at
> the work we did for COIN/SURFconext at

> <http://projectcoin.surfnet.nl/2010/10/fifth-and-final-sprint-of-the-c...>

[Evgeny Bogdanov]

To Niels.
Yes, it is quite close. It is true that the context logic is dependent
on the portal.
We also have some specific implementation, however to make such
contextual gadgets portable over a container
it'd be nice to have opensocial API for this concept.

Right now gadgets have access to owner_id and viewer_id.
And the owner_id is a person, but it can be also a space (or a tab).
That's how we implemented it. Once gadget has owner_id,
it can request either list of friends for a person or a list of
members for a space,
list of gadgets for a person or a list of gadgets for a space.

At the moment, information about a person profile can be requested via
opensocial,
and with this extension a space information (detailed context) can be
requested via opensocial.

To Ryan.

> I also have a proposal where "context" is important. I am not sure
> whether its the same concept though. In my proposal for embedded
> experiences a gadget asks for it's context and that determines what it
> will render. For example, you may have a gadget that renders YouTube
> videos and based on the context it would render different videos. The
> other difference is that the service, in this case YouTube, tells the
> container what the gadgets context should be.

I think the first part goes alone with our proposal (thus your gadget
will have an API to use to retrive
info about context), though the second one is different.

On Dec 21, 3:21 am, rbaxter85 <rbaxte...@gmail.com> wrote:
> This is very interesting and I think it is a great idea.  We
> personally will have a use for this "spaces" concept as we have
> several different contextes inside the same applications where you may
> return different results when getting a users friends.
>
> I also have a proposal where "context" is important.  I am not sure
> whether its the same concept though.  In my proposal for embedded
> experiences a gadget asks for it's context and that determines what it
> will render.  For example, you may have a gadget that renders YouTube
> videos and based on the context it would render different videos.  The
> other difference is that the service, in this case YouTube, tells the

> container what the gadgets context should be.  Here is the proposalhttp://wiki.opensocial.org/index.php?title=Embedded_Experiences.

[Evgeny Bogdanov]

I started to write a document where proposed API is specified:
http://wiki.opensocial.org/index.php?title=Space_extension

It's very drafty but I'll try to make it better very soon.

On Dec 21 2010, 11:42 am, Evgeny Bogdanov <evgeny.bogda...@gmail.com>
wrote:

[James Snell]

Overall, I definitely agree with the fundamental premise with this but it certainly needs to be carefully thought out. There are several discussion points...

1. The "Space" terminology is a bit confusing I think. I would prefer the term "Community" which implies a bit of a broader scope and range of focus. Communities are identifiable entities in their own right, have a membership that may consist of people or sub-communities, and have associated resources such as albums, activities, etc. 

2. In addition to being able to determine the membership of a community, there should be a way of determining the communities a specific user is known to be a member of. e.g. something along the lines of .../@me/@communities and a way of quickly determining whether a user is a member of a given community, e.g. .../@me/@communities/{community_id}. 

3. One thing that was briefly discussed at the OpenSocial 2.0 kickoff last month was the introduction of a mechanism for describing a users membership in a community. For instance, one could imagine a json object that includes properties stating the role of the user in the community, the date joined, a summary of contributions made to the community, etc. 

4. An API for determining which contributions a specific user has made to a community would be interesting as well... essentially something akin to an Activity Stream for the Community filtered by Person. 

5. This raises the question about whether APIs for joining/leaving the community would be required.

- James

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
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.

[Niels van Dijk]

Hi Evgeny,

Could you provide some examples of the 'context' you would like to exchange?
How is that different from group membership, what additional things
would you require to pass to the gadgets?

I would like to think of a space as a set that defines the groups and
resources (albums, messages, activities, gadgets) that have some
relation, for example as part of a collaboration effort. Does that match
your views?

Cheers,
Niels

[Evgeny Bogdanov]

Sorry for long reply. Just came back from vacations.

We've chosen the word "Space" to be more general.
The word "Community" implies people and membership. It focuses on
people.

However, if I am a teacher and I have my courses "Math course" and
"Physics course",
I would not call them "community" even though membership might be
present or might not.

In case of twitter there is no membership (two-directional links) but
rather uni-directional link (I follow, something is followed by).
Something that is followed by is a kind of community=space=context.

Even though the word "Space" might be confusing, the words
"Community","Group" might
be of very narrow orientation, meaning only group of people.

Evgeny

> <evgeny.bogda...@gmail.com>wrote:

> > opensocial-and-gadg...@googlegroups.com<opensocial-and-gadgets-spec%2Bunsu...@googlegroups.com>
> > .

[Evgeny Bogdanov]

Hello Niels,

Yes, it does!

space (equals context) consists of
1) people inside (members, followers, linked people)
2) sub-spaces
3) resources (files, albums, pics, etc)
4) tools (widgets, gadgets, etc.)

example
space = "Math course"
1) Evgeny, Niels
2) sub-spaces "Home exercises", "Exam", "Group 1", "Group 2".
3) pdf course document, schedule document
4) latex gadget, equation editor, exercise gadget

So the space "Math course" is a collaborative environment. People
inside this space (members)
can get access to everything inside. Gadget gets the current context
("Math course" id) and
can retrieve more info about "Math course" (creation date, full name,
rating, etc.) and
list of sub-spaces, list of people inside, list of resources and tools
via Opensocial API
and thus has adapt its behavior to the context.

[Evgeny Bogdanov]

Hello again,

I updated the document with additional explanations and
proposed REST and Javascript APIs.

http://wiki.opensocial.org/index.php?title=Space_extension

If everybody thinks that the word "Community" or "Group" is better
than
the word "Space", we can change it or find a better one.

Does somebody know, what should I do to have this proposal
sent to the reviewers?

Thanks
Evgeny

[Niels van Dijk]

Hi,

I think space is a better name, as it is a rather 'neutral' name. Group
is a very bad name, as a 'space' is made up of, among other things,
group(s), it is also already an existing concept in OS so that
introduces conflict and confusion. Community is better suitable than
group, but in my opinion is not very suitable for desribing such a space
when in an enterprise environment. It would be the same as putting you
collegues in the 'friends' group. Furthermore, a 'space' in the real
world represents a location containing multiple objects (people, doing
stuff, infrastructures etc) where something is going one, which is
exactly what it is in this case as well (people, groups, gadgets,
activities).
So +1 for space from me :)

Cheers,
Niels

[Niels van Dijk]

Hi Evgeny,

This is spot on what we need :)

Cheers,
Niels

[Paul Lindner]

Hi Evgeny,

I see promise in this proposal. Can you commit to working on the
specification changes?

For now I have added your proposal to the 2.0 list.

> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> 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.
>
>

--
Paul Lindner -- lin...@inuus.com -- linkedin.com/in/plindner

[Evgeny Bogdanov]

Hello Paul,

Yes, I can.
I checked out the code from here:
http://opensocial-resources.googlecode.com/svn/spec/2.0/

Is it correct location?

Best
Evgeny

> > For more options, visit this group athttp://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
> --
> Paul Lindner -- lind...@inuus.com -- linkedin.com/in/plindner

[Paul Lindner]

Yes, that's the correct location.

> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
>

--
Paul Lindner -- lin...@inuus.com -- linkedin.com/in/plindner

[Niels van Dijk]

Hi Evgeny,

We've look at the proposed spec a bit more. Please find some comments and suggestions below:

* The current proposal defines 'getters' but not 'setters'. I would propose to add the setters (create, update, delete) as well to be able to use an API call to add a space or application, to add gadgets, groups and people to a space or application, and to add applications to a space.

* In 'People - Get people list' you define: "Gets the collection of all people connected to a "space" or to a "person"
I understand the idea behind getting the people connected to a space, but what is the idea behind getting people connected to people? How is that connection defined?

* I would propose a group service that gets all groups connected to a space like so:

Get gruops list

/groups/{gid}/@all/{type}

Returns

Type	Description
String	Collection of all groups connected to item with id {gid} and with {type} in ("space")

Description

Gets the collection of all groups connected to a "space"

* Most operations work on person and space types, e.g. "Get spaces list", but not on groups.
I think getting groups connected to the space is also valuable. I would therefor propose to update the following:

Get spaces list

/spaces/{gid}/@all/{type}

Returns

Type	Description
String	Collection of all spaces for item with id {gid} and with {type} in ("space","group","person")

Description

Gets list of spaces that belong to a "space", a "group" or to a "person"

* Should activities also be able to support the concept of spaces? something like:

"/activities/" User-Id "/" Group-Id "/" Space-Id [ "/" App-Id [ "/" (Activity-Id / Array<Activity-Id>) ] ] 

using the space id will give all the activities related to the space

* Creating abstract application definitions is a cool thing :) Again I would suggest adding groups there as well so like:

Get applications list

/applications/{gid}/@all/{type}

Returns

Type	Description
String	Collection of all applications for item with id {gid} and with {type} in ("space","group","person")

Description

Gets list of applications that belong to a "space","group" or to a "person"

I welcome all suggestions and comments,

Cheers,
Niels


On 01/18/2011 11:47 AM, Evgeny Bogdanov wrote:

[Mark W.]

I agree with Paul that this looks very promising. I've opened up a new feature request so that you can attach a patch to the spec you've checked out.
http://code.google.com/p/opensocial-resources/issues/detail?id=1135

A couple of procedural things....
We'll need to make sure you are a member of the OpenSocial foundation when you submit the patch. (You'll also need a gmail id so you can use the google code.)

And you should surround your changes with the draft tag.
    <x:draft note="Spaces Support" href="http://code.google.com/p/opensocial-resources/issues/detail?id=1135">My changes here</x:draft>

[Evgeny Bogdanov]

Niels,

by the word "groups" do you mean groups concept that is already in Opensocial, right?

"List of people connected to a person" is the same as it exists currently in Opensocial.

/people/john.doe/@all/person/@all - list of all people connected to john.doe
/people/john.doe/@all/person/@friends - list of friends of john.doe

/people/english.course/@all/space/@all - list of all people connected to english.course
/people/english.course/@all/space/@admins - list of administrators of english.course

Yes, I think activities is a good thing for spaces as well

[Evgeny Bogdanov]

Question about changes.

There are two ways to go.
1) Intrusive: Change directly the existing specs for people

2.1.1.2 Get a list of People
REST-URI-Fragment      = "/people/" User-Id "/" Group-Id

2) Non-instrusive: add proposed specs separately (as additional section)

Which way should I go? Can I submit intermediate patches or only complete one?

[Mark W.]

You can submit patches along the way. I'm more than happy to help commit them.

Just make sure you use the draft tag to surround your changes.

-mw

[Matthew Marum]

Evgeny,

I'm trying to wrap my head around how Applications fit into your proposal.  If Spaces are used to determine context, then I guess Applications are what you call the "functional skin" in your paper?  Could you elaborate on that more?

Matt Marum

[Evgeny Bogdanov]

Applications are normal gadgets.

So, if I created a space "Learn Ruby", I will add into this space the
following gadgets:
"Ruby interpreter", "Code examples", "Google search", etc. Those will
be Applications, that I talk about in proposal to Opensocial.

Gadget "Code examples" can know that it is open within "Learn Ruby"
via Opensocial.
It might use this information and adapt to it (for example, showing
code examples specifically for Ruby language).
Then such gadget becomes contextual.

"Functional skin" is a different concept and it is not what proposed
for Opensocial (though its implementation depend on "Space
Extension").
Since it is implemented as a gadget, it might be added to a space and
become also an Application.
However, the main intention is different. It is to enrich the default
functionality of a container.
Imagine that container allows to see the widgets inside a space only
as one column list: one by one.
But you need a grid functionality: 2x2 widgets on the page. Then you
can write your one widget, that gets a space (via Opensocial),
gets widgets for this space (via Opensocial), and build the 2x2 grid
view. Then you can attach such widget "Functional skin" to a space and
switch views.
If container supports such "functional skins" then you will have a
button like "view this space as ... (default, my_own_view)". If it
does not,
then you just add this widget to a space and when you open it, you
open a different view for a space.

[Matthew Marum]

Ok, that makes sense. 

From what I understand, when you tie a gadget to a space, you then refer to it as an Application as it can take on special meaning and/or alternative representation to the user.  In my mind, when I think application I assume it is something composed of more than one gadget (or includes other components).  Maybe that's just me?  I've tried to come up with a better name but I haven't been satisfied.

I think people have had a lot of good suggestions as far as APIs that should/could be included as part of this proposal.  In your paper, you mention a prototype called Graaasp.  Is that something that can be made accessible or something we could try out at all?  It might be useful (for me) in understanding use cases we might want to support in the spec.

Matt Marum

[Evgeny Bogdanov]

Submitted first patch here:
http://code.google.com/p/opensocial-resources/issues/detail?id=1135

few questions.
1) First question
In the proposal there was a url
/people/{gid}/@all/{type}
I changed it in the spec into
/people/{gid}/{type}/@all

In the specs "gid" = "Person-Id"
Is it ok if I use "gid" = "Context-Id"
and "type" = "Context-Type"

Or somebody could suggest better names (maybe, Parent)?

2) Second question
To get a list of spaces for a person or for another space I use:
"/spaces/" Context-Id "/" Context-Type "/" Group-Id

If we have to have this URL-scheme (four parameters divided by "/")
for all requests for spaces we will have to have a request
(to retrieve info about one space) as following:
"/spaces/" Context-Id "/@space" "/@self"

Though, it seems more natural to use the following request for it:
"/spaces/" Space-Id "/@self"

or just (since anyway we break 4 parameters scheme here):

"/spaces/" Space-Id

What do you think?

[Evgeny Bogdanov]

Matthew,

I will send URL later this week. We are in the process
of finalizing some things to make it production ready.

Evgeny

[Mark W.]

Matt,
I'd like to start us thinking that gadget = application, partly because we still run into the "opensocial gadgets = google gadgets" misnomer. Since we added pub/sub, it's possible for multiple apps to work together. This larger construct usually sits inside some container that provides some context. Although not always, this is some kind of dashboard.

[Evgeny Bogdanov]

Hi Niels,

I was thinking about group services. I am not sure I understand the meaning of groups here.
If I have a group "@friends" where I have few my friends, then what would mean the following requests ?

get groups for a space
get applications for @friends
get spaces for @friends

If we follow the existing notion of groups, then a group is a list of people and every group belong to some user.
We do not have applications for this group (what would it be? I can't come up with real scenario?) and we do not have
spaces for this kind of group.

If we allow to create groups within a space (for example, members, owners, participants), then request
"groups for a space" makes sense as makes sense the request "get list of people for such group".

I have problems imagining other scenarious. Could you please give some?

Best
Evgeny

[Niels van Dijk]

Hi Evgeny,

Thanks for getting back on this!

Although friends is the only group implemented by default, the current
spec allows you to create any group as a collection of people. I'd say
that in none social network usecases for OpenSocial, friends is the less
interesting group and other, none standard groups like e.g.
'FirstYearStudents' or 'eScienceCollabGroup' are much more intresting.

As a simple scenario, I was thinking along the lines of:
A space 'Math101', which has Gadgets 'geometry', 'statistics' and
'algebra', and which is currently assigned to group 'FirstYearStudents'
So the group is member/user of the space much like individual people
could be members. I image the math teacher being the owner of both the
space as well as the group.

get groups for a space 'Math101' would in this case yield
'FirstYearStudents' and e.g. 'SecondYearDropouts'
get applications for @FirstYearStudents would give 'geometry',
'statistics' and 'algebra'
get spaces for @FirstYearStudents would result in 'Math101',
'English101' and well you get the idea.

Does this help?
Cheers,
Niels

[Evgeny Bogdanov]

Yes, it does!

I will add this, I was misinterpreting the group concept ..

[Evgeny Bogdanov]

Niels,

it is a good idea, however I suggest to go incrementally.
I suggest to add first spaces and then (once it's finished) think about groups.

I am not sure I will have enough time to add support for groups now.

Best
Evgeny

[Evgeny Bogdanov]

Hello Mark,

I uploaded the patch here: http://code.google.com/p/opensocial-resources/issues/detail?id=1135

It reflects all changes that were mentioned in proposal. Draft tag is used everywhere I changed something.

Please tell me what you think and what I can do next. I can start adding a patch to shindig or to javascript libraries to support
the proposed changes.

Best
Evgeny

[Niels van Dijk]

Hi Evgeny,

On 02/10/2011 12:15 PM, Evgeny Bogdanov wrote:
> Niels,
>
> it is a good idea, however I suggest to go incrementally.
> I suggest to add first spaces and then (once it's finished) think
> about groups.

You mean for the 2.0 spec or for the actual code when we need to
implement it?
For both I would be happy help out.

Cheers,
Niels

>
> I am not sure I will have enough time to add support for groups now.
>
> Best
> Evgeny

[Evgeny Bogdanov]

Good, if so.

My main problem is with inconsistency that will take place with groups if we consider them as context.
Currently I defined Context-Id and Context-Type that are everywhere either a Person object or a Space object.
For a gadget the context is either a person (it is on person's profile page) or a space (it is on space's page).

If we add a Group into Context-Type then it will make sense in some places but won't in some other ones.

For example, currently in opensocial to request a list of people we have the following request.

= "/people/" User-Id "/" Group-Id (retrieve list of people in Group-Id connected to a User-Id)

I changed it into following

= "/people/" Context-Id "/" Group-Id [ "/" Context-Type ] (here it does not make sense for groups,
since we can't connect a group to another group)

Another example, if gadget retrieves its context it can't be a group, because a group does not have a profile page.

Well, maybe it is worth mentioning what I mean by context here.
If a gadget is on the space's page then context is the space and it is the same as the owner of the gadget.
So in this case, gadget does not have a person-owner but instead space-owner. From this point of view,
all people in a space share the same gadget. This is why I can't imagine how a gadget can be connected to a group.

Another point to mention is that all requests a context specific.
Get applications or spaces for a person does not mean "get all his applications" or "all spaces where he is a member" but only those that are on his profile page, the same with spaces.
If we want to get all spaces where user is a member of, I guess we should add some parameters to request.

So about your scenarious:

get applications for @FirstYearStudents would give 'geometry',
'statistics' and 'algebra'
get spaces for @FirstYearStudents would result in 'Math101',
'English101' and well you get the idea.

to be able to do it, we need with my proposal to have a profile page for a group and add gadgets 'geometry','statistics' and 'algebra' to it,
plus add spaces 'Math101','English101' to this profile page, because at the moment there is no link between @FirstYearStudents and 'geometry' gadget.

Sorry for the long and maybe confusing email. I was trying think it through while writing.
If you want we can discuss via skype, though I'll be on vacation till next Friday (probably no internet)

Best
Evgeny

[Matthew Marum]

Hi Evgeny,

I was looking of the Spaces patch and I noticed something in there that I have a concern with.

For the AppData (2.4) section and the Activities (2.3) section, you've changed the REST URI fragments to include context type as a required segment.

For example..

"/appdata/" Context-Id "/" Group-Id "/" Context-Type [ "/" App-Id ]

I know that in OS2.0 we are allowing breaking changes.  However, REST URIs are often stored or cached by existing applications which make assumptions that the URIs they've used are stable.  I think it is easy to accommodate those still using the old URI scheme.

I propose the new schemes look like this..

"/appdata/" Context-Id "/" Group-Id ["/" Context-Type] [ "/" App-Id ]

And indicate that the Context-Id is a User-Id if the type is left unspecified in URI.

[Evgeny Bogdanov]

Hi Matthew,

I also thought about it.
If we go as you suggest, then the fourth parameter is ambiguous: it
can be either a Context-Type or App-Id,
and opensocial container will have to think about how to distinguish
between them. Or don't you think it is a a problem?

BTW, we decided to add new functionality to our Graaasp application,
so it won't be fully stable in few more weeks.
Anyway, this is a url for it in case you are still interested to know
how we utilize the spaces:
http://graaasp.epfl.ch

Best
Evgeny

[Matthew Marum]

Actually, I do recall thinking about this problem but not sure why I left it off my suggestion.

"/appdata/" Context-Id "/" Group-Id ["/context-type/" Context-Type] [ "/" App-Id ]

You could add a static context so long as it doesn't look like any identifiers or types.  I've seen this pattern in other RESTful web services (like OSLC), but I don't know if I've seen it anywhere in OpenSocial.

You could also check the first character since, as I recall, Context Types start with an "@".

Thanks Evgeny for the link.

Matt

[Evgeny Bogdanov]

Thinking about Applications for a Person or for a Space.

In our site we use in addition to Applications (widgets or gadgets) Assets (or Resources or Data).
These assets might be youtube videos, slideshare slides, photoes, pdf documents, bookmark urls, etc.
They belong either to a Person or to a Space.

MediaItem is a similar concept, however it is limited to audios, videos and images, as  I understand.
Would it be interesting for anybody to have a more abstract concept: Asset or extend MediaItem definition
to become more general ?

[Niels van Dijk]

Hi Evgeny,

Have a look at the discussions in this list regarding connection CMIS ()
and OpenSocial :)

Cheers,
Niels

[Evgeny Bogdanov]

Renaming "context" to "parent" ?

It seems as it might be better to use the word "parent" instead of the word "context"
It seems clearer at least to me.

"/spaces/" Parent-Id "/" Parent-Type "/" Group-Id

"/spaces/" Context-Id "/" Context-Type "/" Group-Id

What do you think?

[Mark W.]

Part of the conversation around CMIS is to have a more complete set of types in OpenSocial, that can then easily be mapped to CMIS. I think we should have document, folder, file, for sure.

[Evgeny Bogdanov]

Hi Mark,

I added the patch for Spaces extension here:
http://code.google.com/p/opensocial-resources/issues/detail?id=1135

I also implemented GET APIs for Shindig 2.0 branch.
I would like now to understand whether people accept this idea and
this spec draft.
If so, I would like to commit to implement the full patch for Shindig
3.0.

Could you please help with this, since I do not have access to
opensocial-resources
or we could discuss it during Thursday conference meeting.

Best
Evgeny

[Paul Lindner]

Evgeny, I added you as a contributor.  That should allow you to prepare a patch for the spec.

[Also anyone else considering contributing let me know and I'll add you...]

Thanks

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
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.

--
Paul Lindner -- lin...@inuus.com -- linkedin.com/in/plindner

[Henry Saputra]

Hi Evgeny,

Could you send again the link to the Space Extension proposal?

I dont think "http://wiki.opensocial.org/index.php?title=Space_extension"
work anymore.

- Henry

On Tue, Mar 29, 2011 at 8:42 AM, Evgeny Bogdanov
<evgeny....@gmail.com> wrote:

> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> 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.
>
>

--
Thanks,
Henry

[Matthew Marum]

I think he had it on the old Wiki, looks like wiki.opensocial.org is now redirecting to the new wiki at docs.opensocial.org.

Can somebody migrate it over?

[Evgeny Bogdanov]

If somebody gives me rights and explains how to do that, I could do it
myself

[Matthew Marum]

Problem is the old wiki isn't accessible using wiki.opensocial.org anymore.  Is the old wiki still accessible through an alternate URL?  I assume at least somebody still has access and could move it over.

[Paul Lindner]

You can find the old wiki at http://wiki.opensocial.myspace.com/index.php?title=Main_Page

On Fri, Apr 1, 2011 at 7:48 AM, Matthew Marum <mgm...@gmail.com> wrote:

Problem is the old wiki isn't accessible using wiki.opensocial.org anymore.  Is the old wiki still accessible through an alternate URL?  I assume at least somebody still has access and could move it over.

--
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
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.

--

[Henry Saputra]

Evgeny,

Is the proposal in
http://wiki.opensocial.myspace.com/index.php?title=Space_extension
still valid?

I think most of the opensocial.* JavaScript namespaces will be
obsolete in 2.0 spec.

- Henry

On Tue, Mar 29, 2011 at 8:42 AM, Evgeny Bogdanov
<evgeny....@gmail.com> wrote:

> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> 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.
>
>

--
Thanks,
Henry

[Evgeny Bogdanov]

You are completely right Henry!

Just uploaded the patch with osapi requests added to Social-
Gadget.xml.
http://code.google.com/p/opensocial-resources/issues/detail?id=1135

For easy view of the changes (not reading the diff or patching the
opensocial specs)
I put the spec 2.0 with spaces here (it reflects the latest patch
submitted):
http://iamac71.epfl.ch/opensocial_space/

The files changed by diff:
Social-Data.xml
Social-API-Server.xml
Core-Data.xml
Social-Gadget.xml

Should I also update the proposal text accordingly ?

Best
Evgeny


On Apr 7, 12:12 am, Henry Saputra <henry.sapu...@gmail.com> wrote:
> Evgeny,
>
> Is the proposal inhttp://wiki.opensocial.myspace.com/index.php?title=Space_extension

[Mark W.]

I created a change to include this in the scope of 2.0 - You can vote on it here:

http://code.google.com/p/opensocial-resources/source/detail?r=1376 

I'll also apply the patch to the main spec so that anyone browsing the draft can read it.

[Mark W.]

OK... check out the main 2.0 stream for the specs. Should have your changes in them for review.

[Evgeny Bogdanov]

Thank you Mark!

If the proposal has enough votes, it means it will be in Opensocial
2.0 and I can submit patches to Shindig, right?

If it is accepted, we should refactor the other things: folders/
documents could belong to a space as well, not only to a person.
Probably some refactoring for ActivityStreams will be required.

[Evgeny Bogdanov]

Hi Mark,

We discussed last Thursday the Space proposal,
since you were not there we decided to ask you
how you see spaces integrated to OpenSocial.

Since space represents a context shared by a group of people
(University course for example),
it behaves similar to the Person concept. Which means Space (similarly
to Person) can have
folders, documents, activitystreams, applications, etc.

So I see two ways to go:
1) We add space and rewrite all the APIs taking space into account
2) We add space and rewrite only few APIs (directly concerning spaces)
Do you have other suggestion?

In any case both in the code and in the spec I try to go in a backward
compatible way,
so that if container does not support space, all API requests should
work as expected with only people.

Best
Evgeny

[Eric]

Evgeny,

Overall, I think the idea of Spaces is a good one. When it comes to
modifying the API, perhaps I'm still confused by their concept and
implementation.

Why not maintain the IDs of each item belonging to a Space within the
Space data construct? So in addition to the fields you've outlined
here: http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Space,
you'd have the following fields:

SPACE DATA MODEL
...
"activities" - Array[String] - An array of Activity IDs that belong to
this space
"people" - Array[String] - An Array of People IDs that belong to this
space
"documents" - Array[String] - An array of Document IDs that belong to
this space
"folders" - Array[String] - An array of Folder IDs that belong to this
space
etc...

This makes it easy to see all items that belong to the space at a
glance. Inversely, the only change I see being necessary to the other
social data constructs is a single field:
"spaces" - Array[String] - An array of Space IDs that this item
belongs to. This enables lookup going in each direction: an item
references each space it is a member of, and a space references all of
its members.

- Eric W.

[Mark W.]

There will still be a final call on closing the votes. The key is that there can be no -1 votes.

In terms of alignment with folders, let's make sure what we do lines up with the CMIS stuff that Eric is looking at.

[Mark W.]

Evgeny,

I apologize that I have not replied earlier, but being out for a week on vacation. Of course, you go on vacation only to work twice as hard when you get back to catch up! Anyway.... I need to study this proposal in more detail and will try to do so in the next two days. I think I read one of the earlier proposals and need to catch up.

In general, when I review this again, I'll look for two things:

1) How this is consistent with the rest of the specification

2) How this will map to existing platforms

Let's take the first point. We've got groups in the spec now, and being very clear how these two things work together will be extremely important. Also, the ownership model, e.g. in thinking about something like application data (appData), it would be good to have appData in a space, so that it's visible by everyone that's in the space. That's the lens I'll be looking through. How does this fit with everything else.

Second point. IBM, Jive, and others have these concepts already, but everyone's done it their own way. This is one of the things that excites me about this proposal, but we need to make sure that there is a clean mapping onto these existing constructs. If there's not, adoption of this will be difficult and there will likely be a rev of this to make it fit.

I hope this makes sense.

[Evgeny Bogdanov]

Yes, it does make sense, Mark.
Thank you in advance!
The only point: in my opinion, the current groups concept (as I
understood it at least)
is different from space concept. If it is not clear from the specs,
maybe I could try to
explain the difference.

Do you have urls IBM, Jive and others have? It'd be interesting
for me to look at them.

[Evgeny Bogdanov]

It might be a good idea Eric.
It is not the case for Person object (there is no albums, mediaitems,
etc. there),
so I do not know if it makes sense to introduce it only for spaces ...

If there is such plan for Person object, then it makes sense for
spaces as well

On Apr 27, 5:13 pm, Eric <woods...@gmail.com> wrote:
> Evgeny,
>
> Overall, I think the idea of Spaces is a good one.  When it comes to
> modifying the API, perhaps I'm still confused by their concept and
> implementation.
>
> Why not maintain the IDs of each item belonging to a Space within the
> Space data construct?  So in addition to the fields you've outlined

> here:http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.x...,

[Evgeny Bogdanov]

Hi all,

As we agreed to postpone space extension integration to version 2.1

I still wonder whether we should add applications (that was proposed as part

of space extension) to OS 2.0 ?

Model

http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Application

APIs

http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-API-Server.xml#Applications-Service

What are your thoughts?

Best

Evgeny

[Evgeny Bogdanov]

btw, I think we should remove spaces patch for now from the main spec, so that people viewing it are not confused

[Richard Vijay]

Exactly. I accept

warm regards,

Vijay A Richard.
 
"And Miles to go before I sleep" - Robert Frost

On Tue, Jan 18, 2011 at 1:11 PM, Niels van Dijk <niels....@surfnet.nl> wrote:

Hi Evgeny,

This is spot on what we need :)

Cheers,
Niels

On 01/17/2011 04:32 PM, Evgeny Bogdanov wrote:
> Hello Niels,
>
> Yes, it does!
>
> space (equals context) consists of
> 1) people inside (members, followers, linked people)
> 2) sub-spaces
> 3) resources (files, albums, pics, etc)
> 4) tools (widgets, gadgets, etc.)
>
> example
> space = "Math course"
> 1) Evgeny, Niels
> 2) sub-spaces "Home exercises", "Exam", "Group 1", "Group 2".
> 3) pdf course document, schedule document
> 4) latex gadget, equation editor, exercise gadget
>
> So the space "Math course" is a collaborative environment. People
> inside this space (members)
> can get access to everything inside. Gadget gets the current context
> ("Math course" id) and
> can retrieve more info about "Math course" (creation date, full name,
> rating, etc.) and
> list of sub-spaces, list of people inside, list of resources and tools
> via Opensocial API
> and thus has adapt its behavior to the context.
>
> On Jan 6, 1:21 pm, Niels van Dijk <niels.vand...@surfnet.nl> wrote:
>> Hi Evgeny,
>>
>> Could you provide some examples of the 'context' you would like to exchange?
>> How is that different from group membership, what additional things
>> would you require to pass to the gadgets?
>>
>> I would like to think of a space as a set that defines the groups and
>> resources (albums, messages, activities, gadgets) that have some
>> relation, for example as part of a collaboration effort. Does that match
>> your views?
>>
>> Cheers,
>> Niels
>>
>> On 01/05/2011 09:59 AM, Evgeny Bogdanov wrote:
>>
>>> I started to write a document where proposed API is specified:
>>> http://wiki.opensocial.org/index.php?title=Space_extension
>>> It's very drafty but I'll try to make it better very soon.
>>> On Dec 21 2010, 11:42 am, Evgeny Bogdanov <evgeny.bogda...@gmail.com>
>>> wrote:
>>>> To Niels.
>>>> Yes, it is quite close. It is true that the context logic is dependent
>>>> on the portal.
>>>> We also have some specific implementation, however to make such
>>>> contextual gadgets portable over a container
>>>> it'd be nice to have opensocial API for this concept.
>>>> Right now gadgets have access to owner_id and viewer_id.
>>>> And the owner_id is a person, but it can be also a space (or a tab).
>>>> That's how we implemented it. Once gadget has owner_id,
>>>> it can request either list of friends for a person or a list of
>>>> members for a space,
>>>> list of gadgets for a person or a list of gadgets for a space.
>>>> At the moment, information about a person profile can be requested via
>>>> opensocial,
>>>> and with this extension a space information (detailed context) can be
>>>> requested via opensocial.
>>>> To Ryan.
>>>>> I also have a proposal where "context" is important.  I am not sure
>>>>> whether its the same concept though.  In my proposal for embedded
>>>>> experiences a gadget asks for it's context and that determines what it
>>>>> will render.  For example, you may have a gadget that renders YouTube
>>>>> videos and based on the context it would render different videos.  The
>>>>> other difference is that the service, in this case YouTube, tells the
>>>>> container what the gadgets context should be.
>>>> I think the first part goes alone with our proposal (thus your gadget
>>>> will have an API to use to retrive
>>>> info about context), though the second one is different.
>>>> On Dec 21, 3:21 am, rbaxter85 <rbaxte...@gmail.com> wrote:
>>>>> This is very interesting and I think it is a great idea.  We
>>>>> personally will have a use for this "spaces" concept as we have
>>>>> several different contextes inside the same applications where you may
>>>>> return different results when getting a users friends.
>>>>> I also have a proposal where "context" is important.  I am not sure
>>>>> whether its the same concept though.  In my proposal for embedded
>>>>> experiences a gadget asks for it's context and that determines what it
>>>>> will render.  For example, you may have a gadget that renders YouTube
>>>>> videos and based on the context it would render different videos.  The
>>>>> other difference is that the service, in this case YouTube, tells the
>>>>> container what the gadgets context should be.  Here is the proposalhttp://wiki.opensocial.org/index.php?title=Embedded_Experiences.
>>>>> On Dec 20, 3:19 pm, Niels van Dijk <niels.vand...@surfnet.nl> wrote:
>>>>>> Hi Evgeny,
>>>>>> Interesting proposal!
>>>>>> We seem to have been thinking along similar lines. Please have a look at
>>>>>> the work we did for COIN/SURFconext at
>>>>>> <http://projectcoin.surfnet.nl/2010/10/fifth-and-final-sprint-of-the-c...>
>>>>>> This has a link to a video demo of the portal we created for the Dutch
>>>>>> Research and Education community which captures many of the ideas you
>>>>>> described in you paper, especially the ability to use group contect to
>>>>>> make gadgets behave more intelligent as soon as these are aware of group
>>>>>> membership. We also have some gadgets that dynamically change behavior
>>>>>> as soon as a group context is added. e.g switch from showing groups a
>>>>>> user is a member of to showing the members of a specific group.
>>>>>> We use group context to create what you call a 'space'  - in our case
>>>>>> presented as a 'tab' - that can hold a set of coherent gadgets and
>>>>>> applications that groups can then use for collaboration scenarios within
>>>>>> R&E. One thing we support is the ablity for a user to 'share' the entire
>>>>>> space or tab with the entire group at once, making it very easy to share
>>>>>> a coherent set of gadgets with a group or team.
>>>>>> I'd be interested to learn if you feel this is what you are thinking
>>>>>> about. Note though, that most of the conext logic is curently handled by
>>>>>> the portal, and not, as you propose, part of the API itself.
>>>>>> Cheers,
>>>>>> Niels
>>>>>> On 12/20/2010 11:38 AM, Evgeny V. Bogdanov wrote:
>>>>>>> Hello,
>>>>>>> We (our research lab at EPFL, Lausanne and I) would like to propose
>>>>>>> and contribute
>>>>>>> to the Space extension for Opensocial V2.
>>>>>>>   Scope of change: Large
>>>>>>>   Reference to existing standard (if applicable)
>>>>>>>   Champion Name: space (or group)
>>>>>>>   Specification editor names and declarations of time commitment:
>>>>>>> Evgeny Bogdanov
>>>>>>> We think that opensocial can be improved by providing a standard
>>>>>>> specification
>>>>>>> not only in a people-focused way but also in a contextual space (or
>>>>>>> group) way.
>>>>>>> Currently, person is a focal point and opensocial allows to retrieve
>>>>>>> friends of person,
>>>>>>> his gadgets, his albums.
>>>>>>> The groups of people are becoming an important part of social life.
>>>>>>> Blogs, Google groups, facebook groups, etc. represent such contextual
>>>>>>> spaces with
>>>>>>> list of members, list of albums/videos/resources, gadgets.
>>>>>>> We think that by providing an extension to opensocial for spaces (groups)
>>>>>>> might improve the openness for social networks.
>>>>>>> Please let me know if you find such extension doable and useful for
>>>>>>> opensocial.
>>>>>>> Best regards,
>>>>>>> Evgeny Bogdanov
>>>>>>> PS: In the attachement one could find the paper describing the
>>>>>>> usefullness
>>>>>>> of these contextual spaces and how opensocial can be extended to
>>>>>>> support spaces.
>>>>>>> Paper is accepted to ACHI conference but not yet published.

[Jacob Floyd]

Why is spaces being postponed to 2.1?

[rbaxter85]

Evgeny, I understand how an application may relate to a space, as in a
space may contain one or more applications. However if spaces is not
in the spec I do not understand where applications would fit. Could
you example?

On May 17, 4:13 am, Evgeny Bogdanov <evgeny.bogda...@gmail.com> wrote:
> Hi all,
>
> As we agreed to postpone space extension integration to version 2.1
> I still wonder whether we should add applications (that was proposed as part
> of space extension) to OS 2.0 ?
>

> Modelhttp://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.x...
> APIshttp://opensocial-resources.googlecode.com/svn/spec/2.0/Social-API-Se...

[Jacob Floyd]

First, I really like the Spaces concept - it makes OpenSocial much more useful for some projects I'm working on.

So, as I read through the spec, I've got some questions. To start off with:

http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Space

What is the difference between the 'name' field and the 'displayName' field?

description of displayName:

Required. The name of this Space, suitable for display to end-users. Each Space returned MUST include a non-empty displayName value. The value provided SHOULD be the primary textual label by which this Space is normally displayed by the Service Provider when presenting it to end-users.

description of name:

The name of this Space, suitable for display to end-users. Each Space returned MUST include a non-empty displayName value. The value provided SHOULD be the primary textual label by which this Space is normally displayed by the Service Provider when presenting it to end-users.

If you were to map the fields from OpenSocial Spaces to Facebook Pages (consider http://facebook.com/opensocialgroup and the api response: http://graph.facebook.com/opensocialgroup), would you say:

• space.displayName = page.name
• space.name = page.username

or, would you reverse that? Or something else?

[Mark W.]

Evgeny,

I'm starting on the app data work now and I'd like to make sure this is consistent with the work that's going on in spaces. I'll copy you on the code when I get it checked in. I'm specifically focused on the alignment of context when working with app data.

[Mark W.]

I noticed that spaces defines the app-id:

"2.2 Application-Id

A Application-Id uses the same format as an Object-Id

Application-Id = Object-Id"

In the past, I believe that app-id has been opaque to the user and defined by the container. I think we should revisit how or if we define app-id here.

[Evgeny Bogdanov]

Hi Jacob,

Yes, it is similar to what you mentioned for Facebook pages.
name is similar to username (which might serve as space id within container)
displayName is what is shown to people.

Description of name was buggy and just taked from displayName.
I changed it in my local version of a patch to:
"The textual identifier for a space. For sites that ask for a unique name of a space (e.g. opensocialgroup or partuza)."

Thanks for finding it!

Maybe we should rename it from "name" to "spacename" or something like this

[Evgeny Bogdanov]

Jacob,

please see this thread for the answer: Mark W. post
https://groups.google.com/forum/?hl=en#!searchin/opensocial-and-gadgets-spec/spaces/opensocial-and-gadgets-spec/vzJDlSbiS44/NnNd2j47cnIJ

[Evgeny Bogdanov]

I think app-id should be still opaque to the user and defined by the container, but we should be able to retrieve list
of app-ids for a space or a person, in case gadget wants to retrieve information on particular application.

  osapi.context.get().execute(function(context){
    osapi.applications.get({contextId: 'opensocialgroup', contextType: 'Space'}).execute(function(response){         
      build_gadgets_list(response.list);
    });
  });


Probably it is more relevant for spaces, but it might be useful for person as well, in case gadget provides
an alternative view for user profile.

[Evgeny Bogdanov]

Can I commit to Spaces extension to OS2.1

Mark, could you please open a feature request as you did for OS2.0

Best
Evgeny

[rbaxter85]

Egveny, you should be able to use the same issue you did for 2.0.
It's labeled with OpenSocial-Next. We should discuss this again at
one of the working sessions.