The Tin Can API is a project that seeks to incorporate all types of learning into a trackable and meaningful framework through the use of activity streams. An activity stream is a series of statements. The form that these statements use is “I did this”.

The Tin Can API Working Group  has been participating in lively discussions, many involving which verbs should be used in the framework. Do we limit the verbs for coherence and easy adoption or do we open it up to allow as many types of learning experiences as possible, but increase the complexity of the specification?

What if I said the answer could be both? Read on to see how this could be the case:

Strict Verbs

Now, this is just my opinion on the matter, but I feel that there should be a set of verbs that at some release of TinCan is “complete”. That is, you can accomplish any sort of normal tracking with it. There should be no room for overlap, either. A verb used with a particular activity should always be tracked the same way within each Learning Record Store (LRS). If you are curious, I’ve taken a shot at determining this list of verbs.

Loose Verbs

At the same time, though, the Tin Can API seeks to enable tracking of the learner’s experience. It is hard to do that with robotic terms such that SCORM used like completion_status and success_status. I think everyone can agree on this aspect, but the question arises of: How much responsibility does the Tin Can API take for enabling diverse tracking?

Breaking It Down

If you look carefully, there is a subtle difference in the function of tracking between the two types of verbs. In the strict verbs, I focused on tracking in the sense of storing data, while in the loose verbs, I focused on tracking as a form of reporting. The Tin Can API is only the former type. It will read, store, validate, and send back data. It is not responsible for reporting. Some other component that communicates with the LRS must do the reporting. It is, however, the responsibility of the LRS to connect the dots between what is tracked and what is reported. Reporting practices will likely vary by community of practice.

I know what you are thinking – “How can the LRS report more than it tracks?” I know what you are thinking – “How can the LRS report more than it tracks?” There are a lot of ways, such as Open Graph, but I won’t get into them here. While these ways can create reporting information from context, there is still a gap.

Closing The Gap

The Tin Can API is an “I did this” model, which is syntactically: <actor><verb><activity>.  When the LRS gets the <verb> part of the argument, we expect it does some sort of check against an expected vocabulary of verbs, makes meaning of it, stores it, and can also retrieve/make meaning of it in the future.  What we haven’t talked about is what if that <verb> is not found?  We would expect that the validator should stop the transaction and report an error. 

 Not So Fast My Friend

Here’s an idea: suppose the Tin Can API allow ANY verb to go through validation PROVIDED it is cast to a verb within the vocabulary.  That is, I could say “Andy hiked 3.1 miles” as <Andy><hiked(experienced)><3.1 mile route> or “Lisa conquered her math test” as <Lisa><conquered(passed)><Math examination>.  This approach could allow us to experience all types of learning content and have some control on what the LRS reports, but at the same time keep the tracking consistent as it should be within a technical specification.  I’d say for added ease of use, that all verbs which are not found by the vocabulary default to being cast into the verb “experienced”. 

I think using the terms “tracking verb” and “descriptive verb” to refer to the two types would be useful going forward if this idea was accepted.  It’s my belief that a verb must have one and only one type.

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