xAPI is a json based data structure that's for expressing the actions taken by a user. It's popular for tracking activity across websites because of it having a standard base schema with flexibility for providing contextual information based on use-case.
LRS do the authentication and schema validation to ensure that structures being added to databases match what is expected. Learning Locker (and many other LRSs) is built on the table-less database technology MongoDB. Mongo allows for pushing a lot of data a lot faster and then allows for retrieval based on matching criteria instead of relational databases like mysql.
- Time on a dedicated part of the task that generated the statement
- Viewed for 10 seconds, instead of just viewed for example
- Student relevant info; section, instructor, role
- System relevant info: Browsing session, browser used, page title / url that implemented the change
- Anything you want (which is good and bad)
Example using extensions
Bad side of Extensions
Extension data is implementation specific so it's not relatable across service providers potentially. This leads to people possibly meaning the same thing (duration on a page for example) but storing that information in multiple ways, thus making it non-relationable. For example "duration:10s" and "page-time:00:10" might mean the exact same thing, but because they were in an extension two completely different ways we can't repurpose them :(
Good side of Extensions: Recipes
Because a lot of people started doing this, the community has started crafting and sharing what are known as xAPI recipes. Recipes are still emerging but allow for an agreed upon way of expressing complex things, like "how long a user watched the video". By doing this, you can relate youtube watch data to vimeo to custom providers and beyond.
Read more about xAPI Recipes
Review of statement structure
Drag and drop the labels where they go on the statement. What item is contextual / flexible vs a core part of the xAPI specification?