Howdy. Wanted to give a quick intro and share a an experiment I'm working on.
My name is Christopher St. John, and my specific interest in DiSo came out of some concerns that developed while playing around hooking up a destination site to various social networks. The technology to do that is straightforward, but the fact that users don't own (or even truly control) their own data means that a lot of cool stuff is impossible in practice.
Over the next week or so (hopefully in time for the Semantic Web Austin mixer on the 17th) I'm hoping to get a prototype running of the Shindig OpenSocial wrapper running with a backend of "the web", specifically the kind of semantic data that DiSo is targeting. (note the "prototype" qualifier: the victory conditions are quite modest :-) )
The first big task (in addition to some tedious but fairly easy coding) is to identify the specific backend formats to target. This is tricky. The considerations include:
- what's best - what's common - what networks are most complete
I don't suppose there's the equivalent of an OpenSocial sandbox for DiSo, is there? (Searching the archives, browsing the Wiki and generally just googling around didn't reveal any obvious candidates, but I could easily have missed something) I suspect I may have to build my own (or start pressuring some friends to add stuff to their blogs :-) ) but I thought I'd ask.
If it's of interest, I'll post the occasional update as things progress,
As for backend data formats... I'm not quite sure what you mean by "backend" but we're using a combination of ATOM, microformats, a new portable contacts schema based on vcard that will be out soon, and eventually (note hand-waving) XMPP. We're also relying heavily on XRDS-Simple to advertise and discover services and OAuth to provide token authorization access to protected resources.
Our model is rather different than OpenSocial as I understand it, as we're trying to architect this in such a way that anyone can host their own friends list (for example) and not necessarily defer to Google, MySpace, etc... for starters.
I don't know if you've seen any of my presentations, but you can check them out to get a sense for the conceptual component building blocks of DiSo:
Let me know what you think and if we can better answer your question. I'm personally very interested in the overlap between DiSo and fbConnect and OpenSocial, so if we can do anything to improve integration points, let us know!
Chris On Sun, Jun 8, 2008 at 11:40 AM, Christopher St John <ckstj...@gmail.com> wrote:
> Howdy. Wanted to give a quick intro and share a an > experiment I'm working on.
> My name is Christopher St. John, and my specific interest > in DiSo came out of some concerns that developed while > playing around hooking up a destination site to various > social networks. The technology to do that is > straightforward, but the fact that users don't own (or > even truly control) their own data means that a lot of > cool stuff is impossible in practice.
> Over the next week or so (hopefully in time for > the Semantic Web Austin mixer on the 17th) I'm hoping > to get a prototype running of the Shindig OpenSocial > wrapper running with a backend of "the web", specifically > the kind of semantic data that DiSo is targeting. (note > the "prototype" qualifier: the victory conditions are > quite modest :-) )
> The first big task (in addition to some tedious but fairly > easy coding) is to identify the specific backend formats > to target. This is tricky. The considerations include:
> - what's best > - what's common > - what networks are most complete
> I don't suppose there's the equivalent of an OpenSocial > sandbox for DiSo, is there? (Searching the archives, > browsing the Wiki and generally just googling around > didn't reveal any obvious candidates, but I could easily > have missed something) I suspect I may have to build > my own (or start pressuring some friends to add stuff > to their blogs :-) ) but I thought I'd ask.
> If it's of interest, I'll post the occasional update as > things progress,
> a new portable contacts > schema based on vcard that will be out soon
I've been increasingly disturbed by the mentions of this I see cropping up. I snooped around and found the SVN today. I can't know exactly what is going on (transparent communities, anyone?) but I get the feeling that it may be inventing unnecessary extras. Especially this "based on vcard"... what's wrong with VCARD/hcard proper?
Sorry for the mystery Stephen. Joseph Smarr mentioned it at Google I/O and we've been waiting on getting a proper spec together before really putting anything out there. The temporary site is up at: http://portablecontacts.net/
We're not sure if that's even what we want to call it yet, but that and Joseph's slides are the only other mentions of this project (look for PPT link):
Eran has been charged with writing up the first go at the spec, but we've all been really busy lately and things have slid a bit.
To your point regarding vcard/hcard, here are the current problems:
1. it's highly unlikely that we'll get the big providers (i.e. Friend Connect/fbConnect) to support hcard/vcard.
2. vcard works for basic profile data, but not for the kind of data that the Facebook and OpenSocial platforms store and want to provide; therefore, we can start with vcard but we need some additional fields, many of which have come from the Social Graph API or XFN (see my post on this issue: http://factoryjoe.com/blog/2008/06/04/inventing-contact-schemas-for-f... )
3. hcard/vcard doesn't provide a convenient, developer-friendly way of doing two-way sync.
4. it would be useful to provide a lighter-weight approach/more API-like protocol than using fatter HTML pages, although embedding contact data in web pages is still valuable and something that should continue to be promoted; it's simply not the way to pass around hundreds of contacts at run-time for thousands or millions of users.
5. we need something that replaces the current methodology of the password anti-pattern, where most people are scraping address books
6. we want to leverage the work that's been put into JCard
7. we would like to offer some basic kind of filtering/querying that is also RESTful
8. we're aiming to invent as little new as possible and to inherit as much existing behavior as possible, while also creating a protocol that is efficient, developer-friendly and that will likely see adoption in a number of contexts, not the least of which are passing around profile data and sharing contact lists.
Anyway, we're not quite ready with something that we want to show for public review yet, but we're getting close. Once we have the basic first draft finished, we'll release it for discussion, just as we did with the OAuth work. Perhaps I shouldn't have mentioned it previously but we are getting close and it's important to know that there is work being done on this problem, and that we're all eager to have a solid solution that is going to be adopted to address the problem that we're all keenly aware of.
Chris
On Sun, Jun 8, 2008 at 1:58 PM, Stephen Paul Weber <singpol...@gmail.com> wrote:
> > a new portable contacts > > schema based on vcard that will be out soon
> I've been increasingly disturbed by the mentions of this I see > cropping up. I snooped around and found the SVN today. I can't know > exactly what is going on (transparent communities, anyone?) but I get > the feeling that it may be inventing unnecessary extras. Especially > this "based on vcard"... what's wrong with VCARD/hcard proper?
> -- > - Stephen Paul Weber (Singpolyma)
> code pwns specs
-- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private
Chris Messina wrote: > Sorry for the mystery Stephen. Joseph Smarr mentioned it at Google > I/O and we've been waiting on getting a proper spec together before > really putting anything out there. The temporary site is up at:
> Sorry for the mystery Stephen. Joseph Smarr mentioned it at Google I/O and > we've been waiting on getting a proper spec together before really putting > anything out there. The temporary site is up at: > http://portablecontacts.net/
> [snip] > Got a wiki to document the existing [anti]patterns that should be > considered?
> http:// Joseph Holsten.com
-- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private
> To your point regarding vcard/hcard, here are the current problems:
> 1. it's highly unlikely that we'll get the big providers (i.e. > Friend Connect/fbConnect) to support hcard/vcard.
> 2. vcard works for basic profile data, but not for the kind of data > that the Facebook and OpenSocial platforms store and want to > provide; therefore, we can start with vcard but we need some > additional fields, many of which have come from the Social Graph > API or XFN (see my post on this issue: http://factoryjoe.com/blog/ > 2008/06/04/inventing-contact-schemas-for-fun-and-profit-ugh/)
> 3. hcard/vcard doesn't provide a convenient, developer-friendly way > of doing two-way sync.
> 4. it would be useful to provide a lighter-weight approach/more API- > like protocol than using fatter HTML pages, although embedding > contact data in web pages is still valuable and something that > should continue to be promoted; it's simply not the way to pass > around hundreds of contacts at run-time for thousands or millions > of users.
> 5. we need something that replaces the current methodology of the > password anti-pattern, where most people are scraping address books
> 6. we want to leverage the work that's been put into JCard
> 7. we would like to offer some basic kind of filtering/querying > that is also RESTful
> 8. we're aiming to invent as little new as possible and to inherit > as much existing behavior as possible, while also creating a > protocol that is efficient, developer-friendly and that will likely > see adoption in a number of contexts, not the least of which are > passing around profile data and sharing contact lists.
Things like existing implementations, components, standards and semantics. That way we can have things to compare against the forthcoming spec. Something like the analysis of resume formats on http://microformats.org/wiki/resume-examples http:// Joseph Holsten.com
On Sun, Jun 8, 2008 at 12:47 PM, Chris Messina <chris.mess...@gmail.com> wrote:
> As for backend data formats... I'm not quite sure what you > mean by "backend"
Well, "backend" for my purposes, since I intend to "skin" the existing distributed social web (what there is of it) with OpenSocial.
> Our model is rather different than OpenSocial as I understand it, as we're > trying to architect this in such a way that anyone can host their own > friends list (for example) and not necessarily defer to Google, MySpace, > etc... for starters.
Hmm, looks like a disconnect, I suspect I explained poorly. I'm going to risk repeating stuff I know everyone already knows in the interest of making sure I'm expressing myself clearly, apologies in advance. So, assumed common definitions:
- OpenSocial is an API for writing Gadgets that plug into social networks. It's also an API for backend server-server communication. As part of that it has a data model covering about 80% of everything existing social networks need (including pretty much all the basics).
- Shindig is an OpenSocial wrapper. That is, it exposes out the OpenSocial APIs, takes care of a bunch of housekeeping, but doesn't actually implement a social network (storage, notifications, etc, any of it). It wraps existing social networks (Orkut, Hi5, etc) but in theory it can sit on top of anything. You implement a set of integration classes that map an underlying implementation.
- DiSo defines a set of methods for publishing your part of the social graph, along with profile data, and even a start on things like notifications. (It's definitely at least that, but it may also be more than that, I'm a bit unclear and need to do some more reading) DiSo mostly (entirely?) re-uses existing little-s semantic web standards like microformats, xfn, etc, etc. It lets you not just own, but entirely control your own data, all the way to hosting it yourself at the edges rather than centrally.
So, Shindig + stuff-like-DiSo = OpenSocial implemented on top of the distributed social web. It means I can implement something for not-Facebook and get DiSo (or similar) for free.
So you get to host your own part of the distributed social graph, but you can also sit any of the thousands of existing OpenSocial applications on top of it.
Well, maybe. That's why it's an experiment :-) I know that most of it will map, but I'm curious about the edge cases. What I'm doing overlaps to some degree with about a million other projects, and part of the point is to learn about some of those as well.
- DiSo defines a set of methods for publishing your part of the social graph, along with profile data, and even a start on things like notifications. (It's definitely at least that, but it may also be more than that, I'm a bit unclear and need to do some more reading) DiSo mostly (entirely?) re-uses existing little-s semantic web standards like microformats, xfn, etc, etc. It lets you not just own, but entirely control your own data, all the way to hosting it yourself at the edges rather than centrally.
So, Shindig + stuff-like-DiSo = OpenSocial implemented on top of the distributed social web. It means I can implement something for not-Facebook and get DiSo (or similar) for free.
I think a big open question that we've not really at all investigated is how to use Shindig ON TOP OF a DiSo "endpoint"... mapping the data sources that Shindig looks for to DiSo data sources... Maybe you can help with this, cks?
Chris
On Sun, Jun 8, 2008 at 9:47 PM, Christopher St John <ckstj...@gmail.com> wrote:
> On Sun, Jun 8, 2008 at 12:47 PM, Chris Messina <chris.mess...@gmail.com> > wrote:
> > As for backend data formats... I'm not quite sure what you > > mean by "backend"
> Well, "backend" for my purposes, since I intend to "skin" the > existing distributed social web (what there is of it) with > OpenSocial.
> > Our model is rather different than OpenSocial as I understand it, as > we're > > trying to architect this in such a way that anyone can host their own > > friends list (for example) and not necessarily defer to Google, MySpace, > > etc... for starters.
> Hmm, looks like a disconnect, I suspect I explained poorly. > I'm going to risk repeating stuff I know everyone already > knows in the interest of making sure I'm expressing myself > clearly, apologies in advance. So, assumed common > definitions:
> - OpenSocial is an API for writing Gadgets that plug into > social networks. It's also an API for backend server-server > communication. As part of that it has a data model > covering about 80% of everything existing social > networks need (including pretty much all the basics).
> - Shindig is an OpenSocial wrapper. That is, it exposes out > the OpenSocial APIs, takes care of a bunch of housekeeping, > but doesn't actually implement a social network (storage, > notifications, etc, any of it). It wraps existing social > networks (Orkut, Hi5, etc) but in theory it can sit on top of > anything. You implement a set of integration classes that > map an underlying implementation.
> - DiSo defines a set of methods for publishing your part of > the social graph, along with profile data, and even a start > on things like notifications. (It's definitely at least that, > but it may also be more than that, I'm a bit unclear and > need to do some more reading) DiSo mostly (entirely?) > re-uses existing little-s semantic web standards like > microformats, xfn, etc, etc. It lets you not just own, but > entirely control your own data, all the way to hosting > it yourself at the edges rather than centrally.
> So, Shindig + stuff-like-DiSo = OpenSocial implemented > on top of the distributed social web. It means I can > implement something for not-Facebook and get DiSo > (or similar) for free.
> So you get to host your own part of the distributed > social graph, but you can also sit any of the thousands > of existing OpenSocial applications on top of it.
> Well, maybe. That's why it's an experiment :-) I know > that most of it will map, but I'm curious about the edge > cases. What I'm doing overlaps to some degree with > about a million other projects, and part of the point is > to learn about some of those as well.
|
