Checking in on Activity Streams for OpenSocial?

[Chris Messina]

Hey Ryan,

Just wanted to follow up on our meeting from a couple weeks ago and see how the translation of Activity Streams into a JSON/OpenSocial-compatible API was coming?

Any updates? Need any help?

Chris

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] bloggable    [X] ask first   [ ] private

[Ryan Boyd (Google)]

Hi Chris,

I've worked on mapping out a format and reviewed it with a colleague yesterday (Arne Roomann-Kurrik, who has a lot of experience with OS).

Worked through each section of the main spec and tried translating.  It still looks a lot like an atom feed though :(

Overall: we discussed lossless mapping from AS atom feeds to JSON such that an aggregator could re-publish AS content in a JSON format without any data loss.  However, this'll be really ugly, and the spec (section 8) only requires preserving elements in the AtomActivity namespace.  Thus, lossless mapping from Atom is probably not necessary for most elements.

Main transformations:

1) Where the spec says "exactly one atom:link element with a link relationship of "alternate" and the type "text/html", with the href attribute containing the URL of the HTML representation of the Object if available," I changed it to a json string property called activityLink with the value being the URL.

2) atom:published ---> activityTime as section 4.2 declares atom:published as not really being the published time, but rather the time the activity occurred

3) atom:content ---> detail 

4) all atom:link elements would be placed into an array called 'links' with objects having properties for each xml attribute of the atom:link.  This appears to be a special case, as most other atom-namespaced elements have only child text nodes.  This convention would be followed for future such cases as well.  The meaning of atom:link isn't explicitly defined in the main AS spec, but is used often in the base schema.  The atom:link used for the activityLink would not be present in this array because it is defined elsewhere.  We want to avoid duplication of data.

General rules:

1) Lower camel case should be used for all object names, '-' is treated as a word delimiter

2) When more than 1 occurrence of an element is possible, a JSON array should be used

3) When an array is used, the property name should be pluralized

Remaining challenges:

1) How to deal with hreflang on an atom:link, as the Atom spec supports more than one atom:link with the same content-type and rel value.   Proposal: when mapping, use first atom:link with content-type='text/html' and rel='alternate' as the activityLink and ignore hreflang. 

2) How to deal with elements not explicitly defined in the AS.ms spec?.  Original proposal: if mapping, ignore anything that's not explicitly covered.  However, atom:link is often used in the base schema, so we'd need to create the array for that (as documented above)

3) How to deal with elements in the activity:context section.  These appear to be arbitrary elements in arbitrary namespaces?  Mapping namespaces to JSON will be ugly.

4) Do you map atom:content to detail always, or only if the entry is an activity explicitly (and not an object)?

5) atom:links are heavily used in the base schema objects.  Should we provide more meaningful mappings for them than what's defined in #4 above?  I'd say we should, though this will add additional non-namespaced properties in JSON for objects.

Next steps:

Write code that takes AS from myspace & facebook and maps them to the JSON format using the above rules.  Publish a comparison on the wiki (along with these rules).  Continue to refine to answer the remaining challenges satisfactorily.  

Thoughts?

Cheers,

-Ryan

[Ryan Boyd (Google)]

(without all the formatting ugliness from textedit)

Hi Chris,

[Mark W.]

Ryan,

Which wiki will you publish this on? It would be great if, wherever
you decide, we cross link it. Something to consider... If it makes
sense to you, maybe we could put this on the OpenSocial wiki as a
forthcoming feature proposal for 1.1. This would be similar to what we
are doing with the OpenAjax Hub integration.
http://wiki.opensocial.org/index.php?title=Spec_Changes

Also, would you be able to put the code in opensource, maybe at the
OpenSocial svn (I think that's where we are going to put prototypes)?

What do you think?

-Mark W.

[Tosh Meston (MySpace)]

Hi all,
I am a dev on the OpenSocial team at MySpace up in Seattle. We've
recently been looking at extending our OS Activities
REST endpoint to include properties for ActivityStrea.ms so that we
may return the data in JSON and other formats. I've basically
used the suggestions from Ryan Boyd to come up with a schema. It'd be
great to hear what you guys think. The Activity
fields below would be additions to those specified in the 0.9 REST
spec here.

http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#XML_format_XSD

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:tns="http://ns.opensocial.org/2008/opensocial"
elementFormDefault="qualified"
targetNamespace="http://ns.opensocial.org/2008/opensocial"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:complexType name="Activity">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element minOccurs="0" maxOccurs="unbounded"
name="actors" type="tns:ActivityObject" />
<xs:element minOccurs="0" name="context"
type="tns:ActivityContext" />
<xs:element minOccurs="0" name="detail" type="xs:string" /
>
<xs:element minOccurs="0" maxOccurs="unbounded"
name="links" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="unbounded"
name="objects" type="tns:ActivityObject" />
<xs:element minOccurs="0" name="source"
type="tns:ActivityObject" />
<xs:element minOccurs="0" name="target"
type="tns:ActivityObject" />
<xs:element minOccurs="0" name="time" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="unbounded"
name="verbs" type="xs:string" />
</xs:choice>
</xs:complexType>

<xs:complexType name="ActivityObject">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element minOccurs="0" maxOccurs="unbounded"
name="actors" type="tns:ActivityObject" />
<xs:element minOccurs="0" name="detail" type="xs:string" /
>
<xs:element minOccurs="0" maxOccurs="unbounded"
name="links" type="xs:string" />
<xs:element minOccurs="0" name="source"
type="tns:ActivityObject" />
<xs:element minOccurs="0" name="time" type="xs:string" />
<xs:element minOccurs="0" name="id" type="xs:string" />
<xs:element minOccurs="0" name="title" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="unbounded"
name="objectTypes" type="xs:string" />
</xs:choice>
</xs:complexType>

<xs:complexType name="ActivityContext">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element minOccurs="0" maxOccurs="unbounded"
name="location" type="tns:Address" />
</xs:choice>
</xs:complexType>

</xs:schema>

Thanks,
Tosh

[Anthony Romano]

Ryan,

The company I am working for is also interested in this. I am
currently tasked with writing a REST endpoint for our activity streams
that will serve up JSON in the upcoming spec. Is there any more
progress on this and is there anything I can do to help?

Anthony

On Sep 17, 9:28 pm, "Ryan Boyd (Google)" <api.rb...@google.com> wrote:

[Arne Roomann-Kurrik]

I know Chris Chabot is working on a XML -> JSON ActivityStreams feed converter in PHP, based off of Ryan's proposal.  I'm copying Chris in here so that he can elaborate, but having a working implementation should go a long way toward showing that the approach is feasible, and may highlight any issues that haven't come up so far.  

I think a great way for people to contribute would be to create and use such tools (as they become available) to see what works and what doesn't with the proposal.  

~Arne