(Note from the editor: This article assumes advanced familiarity with xAPI. Beginners may find that additional study and use of reference material will be helpful to understanding.)
The xAPI profile is one of the most important components of the xAPI ecosystem. Profiles serve as xAPI schema—translations of structures defined in the xAPI specification into a format that computers can read. They can also fulfill the role of a domain-specific data model by defining both expected patterns of xAPI data and the building blocks of those patterns.
The open-ended nature of xAPI has led to inconsistent representation of human activity across xAPI providers; xAPI profiles address this inconsistency. The pioneering work of members of the xAPI profiles working group, including Jason Haag and Russell Duhon, has made it possible to consistently record human activity in xAPI profiles via reusable and referenceable vocabularies, templates, and statement patterns. This requires:
- Defining concepts—verbs, activity types, activities, extensions, attachment usage types, and document resources
- Statement templates—blueprints that outline the IRIs (internationalized resource identifiers) and rules for the fields within a statement
- Patterns—groups of statements matching particular statement templates, ordered in certain ways
Using profiles, it’s possible to represent logic as data, clarifying what information is necessary and what patterns are important, and establishing canonical terminology and definitions. An xAPI profile can be general or granular, encompassing anything from a simple list of terms to a tightly scoped collection of concepts, templates, and patterns specific to a domain. For example, the ADL profile establishes a small set of verbs and activity types, whereas the cmi5 profile is specifically designed for a use case where the learner launches learning content or activity from an LMS user interface. This profile defines specific interoperability rules for several activities: content launch mechanism, authentication, session management, reporting, and course structure.
Ultimately, profiles let developers avoid redundant work, and they improve interoperability between tools and organizations.
Technical overview of xAPI profiles
Profiles use the semantic web standards resource description framework (RDF), web ontology language (OWL), and simple knowledge organization system (SKOS) to publish definitions as linked data. This means that profiles and their definitions must be reachable at canonical URIs, which provide reliability, consistency, and reference ability. Because profiles are published as linked data, they can contain references to other profiles—for instance, a generalized profile like the xAPI Video Profile might be referenced in a domain-specific profile, like one for welder training. This cross-profile referencing system is essential for solving the inconsistency challenges inherent in the open nature of xAPI. To accomplish this, the xAPI profiles specification outlines the requirements for and describes the fundamental functionality of a profile server as well as that of an xAPI profile processor library.
A profile server manages xAPI profiles and hosts a SPARQL (pronounced “sparkle,” an acronym for SPARQL Protocol and RDF Query Language) endpoint containing the RDF information for those profiles. The SPARQL endpoint allows an xAPI consumer or producer to query for current or historic versions of a profile. An xAPI profile processor library is any programming library that implements the statement template validation and pattern validation algorithms.
Validation and contextualization
A statement can specify a profile it conforms to by including the ID of the desired version of the profile as a category context activity. Validation algorithms verify conformance of a single statement or collection of statements to a profile. In the case of a single statement, this validation consists of matching the statement against all defined statement templates in the profile. With multiple statements, validation runs against templates and also against patterns defined in the profile.
The ability to validate conformance allows profiles to provide domain-specific context and thus serve as domain-specific xAPI data models. Scope is one of the most important considerations when writing a profile to serve this purpose. If the domain being modeled is too general, an author may run into issues of conflicting semantic meaning. For example, a profile modeling athletics would need two definitions for the word “shoot”: In the context of basketball, to shoot means to throw a ball at a goal, whereas in a biathlon, it means to fire a gun at a target. Another issue that can arise is the ability to accurately define processes within the domain. Sticking with the athletics profile example, it would be very hard to define the general sequence of events that result in scoring; the steps required vary dramatically between sports. For example, in hockey, scoring requires getting the puck into the goal; in baseball, a runner scores by making it to home plate. To accurately model patterns of activity with a domain-specific result, a profile data model domain must be scoped at the correct level.
Who benefits from using xAPI profiles
Data model authors
An xAPI profile serves as a medium for creating a domain-specific xAPI data model. Previously, when trying to implement a complex system with xAPI from the ground up, the data model author had to essentially create a pseudo-profile. An author typically created a document to track important aspects of the domain, such as key objects and how those objects related to one another, how users interacted with those objects, what those interactions meant, and which patterns of interactions would be reported. The author had to ensure that an analyst could use statements representing these concerns to gain meaningful insight into the domain. The statements were the only standardized representation of these concerns; there was no formalized way to validate the statements against the pseudo-profile, only against the xAPI specification.
Using xAPI profiles, the data model author can represent domain-specific concerns in a standardized format. Statements generated within the domain can be validated against the profile to ensure that meaning is preserved. Patterns of statements can be validated against predefined patterns of activity to ensure that domain-specific logic is not lost in a sea of statements. These features allow the data model author to be more expressive; they also serve as a reference for the xAPI analyst.
A useful—but potentially overwhelming—feature of xAPI is tracking of granular interaction alongside larger completions. This wide range of tracking typically results in large datasets. Statements contained in these datasets may originate from different sources; each source might use xAPI in different ways to convey the same meaning, or it might use the same xAPI field to convey a different meaning. The inconsistency complicates the analysis and can result in missed patterns of activity, incorrect assumptions, and inaccurate reports, and it can slow the process of statistical evaluation.
While an xAPI profile does not eliminate all of these complications, it can help the analyst deal with them. An xAPI profile can provide predefined patterns of activity, help clarify ambiguity, and function as a reference or a statement filter during data discovery.
Profiles can alleviate a portion of the cognitive load implicit to data analytics, potentially resulting in the discovery of patterns of activity not defined by the profile. These new patterns can be reported back to the profile author, setting up a feedback loop between author and analyst that strengthens and matures the profile. The xAPI profile specification outlines strong versioning requirements for this exact reason; profiles are expected to evolve and improve over time.
The value of xAPI profiles to instructional designers has primarily to do with reducing the legwork necessary to instrument xAPI in a learning system, as well as establishing contextual meaning.
For example, an instructional designer working with a video library in a manufacturing organization might be using multiple profiles—say, the video profile and the welding profile in this case. Each profile provides activity definitions, so there is no confusion about what “completed” means, and the instructional designer doesn’t have to manually assign a definition.
The profiles also provide statement templates, meaning that the designer doesn’t have to craft each xAPI statement from scratch. The designer can bring new tools into the system without worrying about terminology inconsistencies—if each tool references the same profiles, the data produced will all be tagged and formatted consistently. Thus, profiles make implementing xAPI a much simpler task for any instructional design team.
The future of xAPI profiles
With all the value that profiles provide now, there is still room to grow. The profile server and xAPI profile processor are the foundation for future xAPI profile tools.
Profiles do not currently support many attractive applications, such as badge assertion, measuring key performance indicators (KPIs), or laying the groundwork for machine learning systems trained on experience data. This should not be viewed as a limitation; rather, it is a strength of the xAPI profile specification that speaks to its longevity.
The specification defines the essential aspects of a profile and leaves the rest up to the xAPI community to build upon in new and interesting ways. This is very much in line with the xAPI specification itself; the authors knew that they would not be able to account for every use case. So, instead of restricting the scope of the specification, they wrote it in a way that allows for extensibility and adaptation. This goes to the heart of the power inherent in the ecosystem of xAPI specifications—they are specific enough to capture data in a structured way, yet provide the extensibility needed to capture data as diverse as experience itself.