The Japanese portal / search engine goo, have gone live with their Shindig-based OpenSocial container. See example user page, goo labs site, developer’s kitchen and documentation (in Japanese). See also announcement from Eiji Kitamura on the shindig (Apache opensocial) list.
Just want to let you know that we officially support OAuth for all Google Data APIs.
See blog post:
You’ll now be able to use standard OAuth libraries to write code that authenticates users to any of the Google Data APIs, such as Google Calendar Data API, Blogger Data API, Picasa Web Albums Data API, or Google Contacts Data API. This should reduce the amount of duplicate code that you need to write, and make it easier for you to write applications and tools that work with a variety of services from multiple providers. [...]
There’s also a footnote, “* OAuth also currently works for YouTube accounts that are linked to a Google Account when using the YouTube Data API.”
See the documentation for more details.
On the YouTube front, I have no idea what % of their accounts are linked to Google; lots I guess. Some interesting parts of the YouTube API: retrieve user profiles, access/edit contacts, find videos uploaded by a particular user or favourited by them plus of course per-video metadata (categories, keywords, tags, etc). There’s a lot you could do with this, in particular it should be possible to find out more about a user by looking at the metadata for the videos they favourite.
Evidence-based profiles are often better than those that are merely asserted, without being grounded in real activity. The list of people I actively exchange mail or IM with is more interesting to me than the list of people I’ve added on Facebook or Orkut; the same applies with profiles versus tag-harvesting. This is why the combination of last.fm’s knowledge of my music listening behaviour with the BBC’s categorisation of MusicBrainz artist IDs is more interesting than asking me to type my ‘favourite band’ into a box. Finding out which bands I’ve friended on MySpace would also be a nice piece of evidence to throw into that mix (and possible, since MusicBrainz also notes MySpace URIs).
So what do these profiles look like? The YouTube ‘retrieve a profile‘ API documentation has an example. It’s Atom-encoded, and beyond the video stuff mentioned above has fields like:
<yt:age>33</yt:age> <yt:username>andyland74</yt:username> <yt:books>Catch-22</yt:books> <yt:gender>m</yt:gender> <yt:company>Google</yt:company> <yt:hobbies>Testing YouTube APIs</yt:hobbies> <yt:location>US</yt:location> <yt:movies>Aqua Teen Hungerforce</yt:movies> <yt:music>Elliott Smith</yt:music> <yt:occupation>Technical Writer</yt:occupation> <yt:school>University of North Carolina</yt:school> <media:thumbnail url='http://i.ytimg.com/vi/YFbSxcdOL-w/default.jpg'/> <yt:statistics viewCount='9' videoWatchCount='21' subscriberCount='1' lastWebAccess='2008-02-25T16:03:38.000-08:00'/>
Not a million miles away from the OpenSocial schema I was looking at yesterday, btw.
I haven’t yet found where it says what I can and can’t do with this information…
OpenSocial’s API reference describes a number of classes (‘Person’, ‘Name’, ‘Email’, ‘Phone’, ‘Url’, ‘Organization’, ‘Address’, ‘Message’, ‘Activity’, ‘MediaItem’, ‘Activity’, …), each of which has various properties whose values are either strings, references to instances of other classes, or enumerations. I’d like to make them usable beyond the confines of OpenSocial, so I’m making an RDF/OWL version. OpenSocial’s schema is an attempt to provide an overarching model for much of present-day mainstream ‘social networking’ functionality, including dating, jobs etc. Such a broad effort is inevitably somewhat open-ended, and so may benefit from being linked to data from other complementary sources.
So – my RDF version. At the moment it is merely a list of classes and their properties (expressed using via rdfs:domain), written using RDFa/HTML. I don’t yet define rdfs:range for any of these, nor handle the enumerated values (opensocial.Enum.Smoker, opensocial.Enum.Drinker, opensocial.Enum.Gender, opensocial.Enum.LookingFor, opensocial.Enum.Presence) that are defined in enum.js.
I’ve tested the output using the OwlSight/pellet service from Clark & Parsia, and with Protege 4. It’s basic but seems OK and a foundation to build from. Here’s a screenshot of the output loaded into Protege (which btw finds 10 classes and 99 properties).
OK so why might this be interesting?
- Using OpenSocial-derrived vocabulary, OpenSocial-exported data in other contexts
- databases (queryable via SPARQL)
- mixed with FOAF
- mixed with Microformats
- published directly in RDFa/HTML
- Mapping OpenSocial terms with other contact and social network schemas
This suggests some goals for continued exploration:
It should be possible to use “OpenSocial markup” in an ordinary homepage or blog (HTML or XHTML), drawing on any of the descriptive concepts they define, through using RDFa’s markup notation. As Mark Birbeck pointed out recently, RDFa is an empty vessel – it does not define any descriptive vocabulary. Instead, the RDF toolset offers an environment in which vocabulary from multiple independent sources can be mixed and merged quite freely. The hard work of the OpenSocial team in analysing social network schemas and finding commonalities, or of the Microformats scene in defining simple building-block vocabularies … these can hopefully be combined within a single environment.
Via Rajdeep Dua on shindig-dev, “Shindig : An Architectural Overview ( PHP Version)”
Shindig is the Apache-incubated project to build an opensource implementation of the Google-and-friends OpenSocial platform for gadgety social networking. Most activity on the list is around the Java version, but a PHP effort/port is also underway.
This article follows the earlier “Architectural Overview of Shindig , an OpenSocial Reference Implementation“; both are based on work-in-progress code from Shindig svn.
One part that caught me eye was this handy (if inaccessible) overview of the schemas:
Figure 7 provides the details of various classes which represent and store the social graph on the client side for OpenSocial APIs.