An Introduction to xAPI for Educational Chatbots

Edtech companies often don’t make it easy for administrators, instructors, or even students to make data-informed decisions about their applications.  Many edtech applications are walled gardens, particularly where data is involved.  While they may offer valuable services, these applications may not make it easy to view or use the data they collect.  Indeed, they may not even collect the data that educators and students want to know.  Instructors have to try to design a cohesive learning experience while the learning data of the experience becomes increasingly fragmented and inaccessible. Educational chatbots can suffer from the same problem if not designed well. 

When developers design systems to make data available, the data from interactions with bots can help learners, faculty, and admin make decisions to improve the learning environment.  Opening up the data can also benefit developers because their chatbot applications would have more flexibility and may even get better use.  To realize these benefits, chatbot developers should understand how xAPI can make the data of a chatbot application accessible and useful.

What is xAPI?

Experience API (xAPI) is a learning specification that standardizes the structure of learning data.  It was developed by the Advanced Distributed Learning Initiative along with Rustici Software as a replacement for SCORM, a specification that had significant limitations.  The full xAPI specification is available on ADL’s Github.  Rustici Software’s Github has code libraries to support xAPI integration into applications.

Beyond being openly available for free use, xAPI has been developed with underlying principles (“freedoms”) that give control over data collection to educational stakeholders.  One should be able to create statements for various learning activities in a variety of contexts (Statement Freedom).  Additionally, xAPI statements can be sent from any device that is set up to send statements (Device Freedom).  Also, learning data should be free to move between storage locations and devices (Workflow Freedom).  The flexibility these freedoms provide can help educational organizations use xAPI through applications to match the needs of their organization.

Building an xAPI Statement

An xAPI statement is a description of a learning experience.  Consider how an instructor might describe what a student has done in their class: “Sumin got an A on the fractions quiz last week.”  It’s clear who’s involved (Sumin), what they did (got an A), and the specific activity they worked on (last week’s fractions quiz).  xAPI statements follow a similarly intuitive structure with three components – actor, verb, and object.  Instead of using a sentence, though, statements are written in JSON (JavaScript Object Notation), a common format for sending data between web applications.

Let’s build a statement for the following learning activity:

Tak Ji Hoon completed the preposition flow in Grammar Bot.

To start with, the actor is an individual who did something.  Often, it will be a single student, but it’s possible to also write statements based on an instructor, application, or even a group.  In a chatbot, the actor would usually be the person interacting with the bot.  “Tak Ji Hoon”, a student, is the name of our actor.  We will include their name and email address.

{
    "actor": {
        "name": "Tak Ji Hoon",
        "mbox": "mailto:test@test.com",
    }
}

Next, we need to tell what the actor did using a descriptive past tense verb.  The verb can capture many activities within a chatbot like switching flows or interacting with a resource.  ADL has outlined many verbs you can use in xAPI statements.  The verbs come with brief descriptions that help maintain a common understanding of what each term means.  This shared understanding supports consistency between applications, making it simpler for educational stakeholders to understand statements.  The specification supports multiple languages.  However, translated content may have variations compared to the English terms because there doesn’t seem to be an official registry for equivalent terms across different languages yet.

For our statement, we will use the verb “Completed” to represent what Ji Hoon did.  We will also add the Korean equivalent, “완료했다”. 

{
    "actor": {
        "name": "Tak Ji Hoon",
        "mbox": "mailto:test@test.com",
    },
    "verb": {
        "id": "http://adlnet.gov/expapi/verbs/completed",
        "display": {
            "en-US": "completed",
            "ko-KR": "완료했다"
        }
    }
}

The last component is the object – what the actor acted on.  The object section is flexible enough to describe various online and offline activities, such as quizzes, group work, and materials.  The specification recommends the object section include a name, an activity type, and a description.  For a chatbot flow, you may want to use the flow name and a description of the flow provided by the user.  Getting a translation of these two items through an application may be difficult. It’s worth considering how to let educators themselves set these descriptions from the application.

The id field has different options to choose from.  It could use the URL of an activity, such as a link to an LMS page or a website.  Many edtech applications don’t support linking directly to specific activities or pages.  That’s where the other option comes in handy.  Similar to the verb, the xAPI registry has a list of activity types that one can link to.  In our chatbot’s case, a link would not go directly to the flow we want, so we will use the “assessment” activity link as an id.

{
    "actor": {
        "name": "Tak Ji Hoon",
        "mbox": "mailto:test@test.com",
    },
    "verb": {
        "id": "http://adlnet.gov/expapi/verbs/completed",
        "display": {
            "en-US": "completed",
            "ko-KR": "완료했다"
        }
    },
    "object": {
        "id": "http://adlnet.gov/expapi/activities/assessment",
        "objectType": "Activity",
        "definition": {
            "name": {
                "en-US": "Preposition Quiz",
                "ko-KR": "전치사 퀴즈"
            },
            "description": {
                "en-US": "A quiz at the end of the self-study lesson on prepositions in Grammar Bot.",
                "ko-KR": "문법봇의 전치사에 대한 자습 수업이 끝날 때 나오는 퀴즈입니다."
            }
        }
    }
}

The actor-verb-object model makes up the core information of an xAPI statement.  The combination of these components lets people describe many kinds of learning activities.  However, xAPI also has other optional sections, such as results or context, that allow for additional information.  It’s even possible to subset one statement within another.  For our example statement, we might want to include the student’s quiz score and time taken.

{
    "actor": {
        "name": "Tak Ji Hoon",
        "mbox": "mailto:test@test.com",
    },
    "verb": {
        "id": "http://adlnet.gov/expapi/verbs/completed",
        "display": {
            "en-US": "completed",
            "ko-KR": "완료했다"
        }
    },
    "object": {
        "id": "http://adlnet.gov/expapi/activities/assessment",
        "objectType": "Activity",
        "definition": {
            "name": {
                "en-US": "Preposition Quiz",
                "ko-KR": "전치사 퀴즈"
            },
            "description": {
                "en-US": "A quiz at the end of the self-study lesson on prepositions in Grammar Bot.",
                "ko-KR": "문법봇의 전치사에 대한 자습 수업이 끝날 때 나오는 퀴즈입니다."
            }
        }
    },
    "result": {
        "score": {
            "scaled": 0.82
        },
        "success": true,
        "completion": true,
        "duration": "PT1127S"
    }
}

Storing Statements in an LRS

After an application generates a valid xAPI statement, the application sends the statement to a special database called a Learning Record Store (LRS).  An LRS is specially designed to receive, validate, and store xAPI statements.  It acts as a repository for statements from all applications you point toward the database.  In addition to our grammar chatbot, the LRS might include statements from the LMS, courseware, computer lab exercises, and other activities.  Many LRSs have internal analytics dashboards that can help you make sense of this data.  The centralization the LRS provides simplifies the analysis of data from disparate systems and practices across courses.  

Data stored in an LRS is not locked into a particular vendor.  All xAPI statements are JSON with a structure that matches the specification.  Thus, all LRSs are designed to understand and accept this specification.  Many have options to export the data into a package that can be uploaded to another LRS.  That means you can transfer xAPI data between LRSs, and even move it between a service provider to a self-hosted system (and vice versa).

Below are some of the most popular LRSs (in no particular order).

• Learning Locker

• Watershed

• Veracity Learning

• Yet Analytics

Conclusion

Educational organizations should be able to make use of data to get a comprehensive picture of learning activities.  By building in support for xAPI, edtech applications can not only make data available to students, faculty, and admin but also help their application fit into the broader ecosystem of an educational organization. 

The community around xAPI is growing. More vendors have adopted (often limited) support for the specification. Additionally, learning and development professionals have taken an interest in how xAPI can support their organizations. These professionals work at a variety of organizations promoting learning endeavors, from public schools to universities to corporations. Groups like the xAPI Cohort are helping those interested learn more and even work with the specification. 

Given this interest in and the general utility of xAPI, chatbot developers should consider how to incorporate xAPI reporting into their applications. This post has introduced what xAPI is and how it might relate to chatbot development.  Take a look at the next post to see how to integrate xAPI into a Rasa project.