Representing Objectives in xAPI
In part 1 of this series, What Happened to the Learning Objective, we discussed the importance of the learning objective and the role of the objective in the Total Learning Architecture. Of course, if we are going to track a student’s performance and competency across the course of their lives to create an Enterprise Student Record, this data must be consistent. While easy to state, garnering consistent data from multiple systems, institutions, and activities can be a challenge.
xAPI Statements – The Building Blocks
xAPI statements follow a basic pattern of Actor-Verb-Object. The Actor is the person or group of people the statement is about, the Verb is the thing they did, and the Object is what they did it to. Let’s step through an example where our object is an objective:
Actor: Jane Garrett
Verb: Completed
Object: Objective: Demonstrate Lockout/Tagout Procedures
If you think this statement doesn’t give me much detail so far, you are correct. For consistency, these pieces of data are tied back to specific “IDs” in xAPI. For example, an actor may be identified by an email address or “account” like a student, employee, or military ID number. Verbs are further defined using a url/iri and objects have a unique id. Essentially building a web of auditable and consistent data. You can find more information for a deep dive here.
Getting to the Details – Results and Extensions
Beyond using standard verb and object definitions, xAPI allows for Results and Extensions. Results are just that, how the actor performed the verb on the object. If that object is a test, the result could be that the Score was 95% and the Success status was True. Each assignable unit can include a MasteryScore in its cmi5 course structure to define if someone passed or failed the AU but doesn’t identify the individual learning objectives that were mastered so this information needs to be instrumented when the content is developed.
Extensions are a bit different than results to allow developers to add additional information to a statement. Extensions may be included in the statement’s Object Definition, Result, or Context. For example, if a book is the Object, the book’s ISBN number could be included as an extension. A Context extension may include a device type to differentiate learners that completed an activity on a mobile device versus a computer. Because extensions can hold just about any data, they are incredibly powerful but, to turn a Stan Lee phrase, “with great power comes great responsibility.” Because the organization or developer defines the extension, it’s a best practice to include a unique URL/IRI to ensure that data is being used consistently. That’s why the extension key should normally be a globally unique IRI/URI. Extensions should also be evaluated for data privacy concerns since they could, potentially, expose personally identifiable information.
So what do we do with all this data? Read part 3 of this blog seriese here.
Mr. Welder’s career is founded in traditional instructional design and computer-based training development. He is a certified Development Dimensions International facilitator, a Kirkpatrick Certified Evaluator and facilitator of the Ohio State University curriculum development program. In addition to working in industry, Mr. Welder has held adjunct faculty positions at Bowling Green State University, Ohio and the College of the Mainland, Texas. Mr. Welder has been published in both Training Magazine as well as US Business Review.