The Tin Can API Working Group has been busily discussing verbs in the <actor><verb><activity> statements that make up the Tin Can API.  While we debate whether the Tin Can API is modeled after Activity Streams as a concept or is in accordance with the current Activity Streams specification, let’s look at how activities are handled in each.  To disambiguate all of the Activity Streams specification activities, we will look at the JSON bindings of each of the Tin Can API and the Activity Streams specifications. 

Basic Activity Streams concepts

An entire “statement” as coined by the Tin Can API is defined as an “activity” in the Activity Streams spec.  It consists of <actor><verb><object> at a minimum.  It also needs a publishing timestamp, which we will get to later.  The <object> could be an activity since it is what the actor is doing with the verb, or it could actually be an entirely new activity as in an example “Jane shared [that] John posted a photo to his album”.  In this respect some pretty complex statements are possible.  An actor is required and is expected to have a 1:1 relationship with its value of type <object>. A verb is required in the sense that if one is not specified, “post” is used.  An <object> (this time in the sense of the activity the actor is doing) is also expected to share its properties with any verb defined in the spec.  The verb also drives whether a <target> in the resulting stream is necessary or not.

The Activity Streams spec is a bit curious in how requirements are handled.  The concepts of activities and objects are pretty wide open with nesting, as are verbs, which are expected to be mostly extensions that define themselves.  Activities (in the form <object>) aren’t required to have any properties, but some that are reserved and recommended take on the form of web page and publishing properties such as author, icon, published, image, and summary.  There is also an expectation of a launched media resource having attributes of height, width, and duration.  There are many other defined behaviors for other <object> types that can be found within the Activity Streams spec site.  For the openness of the spec, I found it curious that objects were so strongly defined and wonder about the inability to have a shared actor experience within a single activity.

Comparison with Tin Can API statements

In contrast, the Tin Can API statement is structured as <Actor (learner)> <verb> <object>, with <result>, in <context>.  Some of the concepts are similar, with the <object> expected to be the actual activity.  There are more verbs explicitly defined in the Tin Can API, and the allowed object types, results, and other attributes are directly determined by the chosen verb.  The <actor> field is wide open in the Tin Can API.  An <actor> isn’t even needed within a statement (system will infer based on authentication if an <actor> is not provided) and can contain multiple participants or even a pre-defined structure of participants.  Unlike the Activity Streams spec, an object must have an “id” that corresponds to a URI.

The Tin Can API has many more defined constructs for tracking information pertinent for the learner.  While the Activity Streams spec focuses on the publisher, the Tin Can API focuses on the learner with captured results such as “score”, “success”, “completion”, “attempt”, and “response”.  Similar to Activity Streams, pretty much anything is extendable.  The Tin Can API does not require timestamps or any similar construct.  The Tin Can API also allows definitions which take on the form of metadata as well as the entire <context> object to provide information on how an activity is to be used.  Activity Streams offer by default a summary field, but of course, can be extended.

Analyzing the differences

So what is the takeaway across the two specs?  In my assessment, I don’t see a lot of differences that couldn’t be mitigated.  The biggest roadblock would be the 1:1 actor requirement in the Activity Streams spec.  This would require a lot of fragmentation for multi-learner activities to fit within the Tin Can API spec (one statement about a team would become many separate statements for both the original statement and to link the actors together).  The vocabularies of each would need to expand to include the best practices of the other.  There aren’t any strict rules within the specs for which attributes and results go with which verbs, but it is implied that a community know what they are collectively doing before agreeing on a verb set to ensure interoperability.  Profiles would be created by communities of practice that enforce certain behaviors and taxonomies.  For example, ADL would likely define a legacy SCORM wrapper that would enforce the same rules as the SCORM Run-Time Environment (RTE) on things like score, completion, and success statuses.  In contrast, a virtual world training community would likely define hundreds of verbs that relate to the large context of behaving in another world.  I think the bigger challenge once both of the specs mature is reaching consensus within the profiles and a balance between diversity and adoption.

The important thing is that the underlying architecture and communities behind these efforts are similar, expansive, and open.  We’ll continue to monitor the work done on Activity Streams and work with the ADL community to implement the solution that makes the most sense.

Please join us in the Tin Can API Working Group if you would like to discuss this further. Thank you!