Contact Us Support Forum Get Email Updates

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Experience API questions:


Archive for the "Statement Anatomy" Category

Statements come from all kinds of places: content created in authoring tools, mobile apps, learning platforms and business systems. It’s not always immediately obvious which application the statement came from, which might be useful to know. This blog explains how you can tag the statements your tool or product generates and why that information is useful.

We’ve worked hard to make the Tin Can (xAPI) spec as clear as possible and have required Learning Record Stores (LRSs) to validate incoming data to ensure the same data structure is always used. There’s no way for statements to be sent to a conformant LRS unless they follow the prescribed data structure, and you’ll find that the major LRSs are strict with the data they accept.

1 Comment

On Tuesday, March 31st, 2015, we hosted a webinar about nine practical use cases of the Experience API (xAPI). As usual, the attendees had more questions than we could answer during the live webinar, so we’ve posted the questions and Andrew Downes’ answers here.


Q: LRS is learning XXX system? quick definition please
Q: what does LRS stand for?
Q: how does an LRS differ from an LMS?

A: Learning Record Store. There’s a great explanation of what an LRS is and how it differs from an LMS here: ../learning-record-store

Q: I’m in the US…and I’m not familiar with the way Andrew is using “bespoke”.
Q: What does “bespoke API” mean?

A: From the Wikipedia definition of bespoke: “altered or tailored to the customs, tastes or usage of an individual”. Many products and systems have an API that’s specific to that individual system. If you want to integrate with that system, you need to tailor-make an integration with that system and you won’t be able to re-use that work with another system. The point of xAPI is that you can do the integration work once and it will work with any xAPI conformant system. MORE…

No Comments

Who Did It?

Posted by

Categories: Deep Dive, Statement Anatomy, xAPI

Posted 19 November 2014


Was it the butler, or Mrs Brown with the Candlestick in the Conservatory? Choosing the actor of your xAPI statement can be a bit of a puzzle…

Brian Miller’s deep dive into Agents is a great introduction into the technical structure of the Agent object and overview of the various places an agent can sit within the statement: as the actor, as the object, or as the team or instructor property of the context. This is a must-read for developers implementing xAPI.

As designers, we’re presented with a slightly different question: who is the Agent that will be the subject of our statement? In many cases the answer is straightforward— the Agent is whoever did the thing:

Bob completed this course
Sue watched that video

But what if there’s more than one person involved in the experience? Did Sue mentor Bob or was Bob mentored by Sue? Did the manager observe the worker or was the worker observed by the manager? How do we choose? This is exactly the question Jessie Chuang asked on the xAPI Google Groups, so let’s dive into the answer!

No Comments

Deep Dive: Attachments

As network speeds and the processing power of devices improves, the size of the files we use to capture our experiences, be they photos or other graphics, videos, or complex documents, increases. We need a way to associate these ever-growing files with the metadata capturing the rest of the experience. This data comes in all shapes and sizes, particularly these days, and as flexible and readable as JSON is, it isn’t great for capturing large amounts of binary bits, but the Experience API specification allows for including attachments with statements for this purpose.

Attachment handling is implemented through a combination of an ‘attachments’ property of the Statement object itself and optional inclusion of copies of the files themselves. Note the use of plurals here, a single Statement may be associated with multiple files, therefore the ‘attachments’ property of a Statement takes an array as its value. The elements of this array are objects with properties, some required and some optional, that provide metadata about the included attachment.


A little over a month ago I presented the “Anatomy of a xAPI Statement” webinar as follow up to our continuing Deep Dive series of blog posts. Despite some Q&A time at the end, I didn’t have a chance to answer all the questions, here is the Q&A for that webinar.

Q: Will you be sharing the slide deck?

Q: Will a recording of this webinar be available?

A: Slides are available on slideshare, recording is available at ../webinar.


Q: Why was JSON chosen for the Experience API?

A: Several reasons led to its adoption most of which build on the others. At its core JSON is essentially “executable” (technically “evaluatable”) in JavaScript which has led to it being the primary choice for AJAX (or remote requests) in browsers as JavaScript is the single choice for direct browser script execution. The support in browsers has then led to a need on the server side to have good, well established library support in lots of development languages. Because of the common use as a transfer format its minimalist nature was also an important consideration. Finally, it is fairly human readable, certainly relative to XML, but still provides the ability to arbitrarily nest data objects. (See slide #4)


No Comments