First, I want to point out that RDF is not a representation, it's a
way to model data and it's multiple ways to represent that data (in
XML, JSON, etc.). I think the real question is: how do we enable
OpenSocial to hook into the RDF-based web of "Linked Data" that is
rapidly growing up around scientific data, government open data and
the academic world. I'm not going to go into the benefits of Linked
Data in this post, but I will disclose that I work for a company that
uses RDF as a common data model to enable loosely coupled integration
across our web application products (see also Jazz Integration
Architecture [1] and OSLC [2]). We'd like to be able to integrate with
OpenSocial services in the same ways.

I'll explain the basics of RDF.  RDF is way to model web data and ways
to represent that data in XML, JSON, Turtle, etc. The RDF data model
is simple, we have resources identified by URIs and property values
associated with those resources. Resources can have types, each type
is identified by a URI. Property types have URIs too. Once you have
defined your data model in terms of RDF types and properties, you can
represent resources and their properties using RDF representations.
There's RDF/XML for XML, there's RDFa for embedding properties in
HTML. There's are JSON representations too, but not a standard for
JSON yet

So, to bring OpenSocial in-line with the world of Linked Data, we
would define each class of OpenSocial objects as an RDF type, with a
URI. We would define each OpenSocial property as an RDF property, with
a URI. In some cases, we'll want to use existing properties, like the
Dublin Core title, name, etc., and in some cases we'll want to define
entirely new types and properties.

As a starting point, I think we would do the following:
* In OpenSocial v2, we would define all OpenSocial objects and
properties as RDF types in the OpenSocial Specs. This means simply
assigning a URI to every class and every property we define, using
standard properties where appropriate and defining new ones as needed.
Object and property names would rename the same and we'd have what is
essentially an RDF mapping built into the spec. Existing OpenSocial
representation formats would stay the same, but we'd add some new RDF
representations
* We'd introduce an optional new OpenSocial spec that services MAY
implement: the OpenSocial RDF Specification. The specification would
simply require that a service provide RDF representations of it's
resources via content-negotiation. The service could offer RDF/XML or
HTML with RDFa, JSON/RDF or all of the above.

That's a starting point and I think we could come up with some other
ideas if we thought more about use cases. Anybody else interested in
aligning the worlds of OpenSocial and Linked Data?

- Dave

[1] https://jazz.net/about/about-jazz-architecture.jsp
[2] http://open-services.net

This is probably one of the topics/proposals that could be brought up
in the next OpenSocial 2.0 kickoff meeting:

http://www.eventbrite.com/event/1103748341/estwbreg

- Henry

Was there any discussion on this during the kickoff?  I don't see it on the
table for 2.0 currently.

There's still time to accomodate RDF.  Is there something specific you
had in mind?

Dave,
While we've had a number of discussions on this off-line, as these come up,
where I tend to trip over myself is being able to clearly articulate the
tangible benefits of doing this. This is probalby because I am not as
familiar with RDF as you are. Would you help me get my head around this with
a scenario? You mention that there's a growing amount of scientific and gov
data. Is the idea that I can link all of the data sets together (across
sites) and b/c RDF gives me a way to introspect on the kind of data, I can
do more intelligent things?

Thanks!

-Mark W.

OpenSocial could have used the RDF data model to specify resources and
properties, but it didn't and that's fine. It's possible to develop a
mapping from the OpenSocial model to RDF, but is there great benefit
to doing so. I don't know.

OpenSocial and RDF are two different ways to achieve integration
between web applications/sites.

In the OpenSocial model, site A can provide a gadget that plugs into
site B. The gadget provides a UI in site B and can access social data
via a standard protocol in site B and whatever data in site A it needs
too via whatever protocol.

In the RDF model, all sites make resources available at URIs and
provide property values about those resources, perhaps via content-
negotiation (i.e. client requests RDF/XML) or by embedding them in the
HTML (i.e. RDFa). That's how Facebook Social Graph works. Taking the
model further, sites make it easy for users to establish links between
resources (e.g. OSLC delegated pickers), and links are, of course, RDF
properties.

A site could use both models and allow both Gadgets and RDFa markup in
the resources that it provides. For example, what if an OpenSocial
Gadget was embedded in a blog entry page that is marked up with RDFa
data, i.e. property values about the "permalink" URI of the blog
entry. An OpenSocial app can get those properties now by HTTP GET the
blog entry URI and parsing the RDFa properties, no?

I might have reason to think more on this topic this year, but I can't
commit to a 2.0 proposal now.

Thanks,
Dave

Dave,
So wouldn't OpenSocial's REST APIs fall in the same category as RDFs URI
technique, e.g. http://somesite/people/... ? So in the RDF model, I can find
out what properties are sent back to me because I can do the content
negotiation, right? In OpenSocial, because I've got a spec, and a site
declares they are a container, then I "know" what they support because a)
the spec, b) the supported fields call. Am I in the right area here, or
completely confused (or both!)? If so, would simply providing the RDFa
"mapping" to OpenSocial and making this available as part of the discovery
be enough?

Would an accurate summary of your gadget scenario above be that there is
benefit in having a way for the opensocial app (gadget) understand the other
constructs that exist within the container that renders it? If so, then
maybe this falls in the container discussions that have been going on.

Thoughts?

-Mark W.